[MPlayer-G2-dev] Re: g2 config - restart...

[Arpi]

Hi,

> > > Until now imho there is no big problem with implementing such stuff.
> > > The only problematic thing that i can see is the current main problem
> > > of the 'new' config code in G1 : dynamicly allocated stuff vs. mem
> > > leak vs. static values.
> > > If we strictly deal with struct that are create by (properly) copying
> > > the default stuct it's not a problem as we will only have dynamiclly
> > > allocted stuff.
> > > But if we also want to operate on 'normal' vars (we probably want)
> > > then it's a problem.
> > > In current G1 it's solved with a hack (when options are registered
> > > in the context saving system those who use dynamicly allocted
> > > mem (like string) have their initial value replaced by a copy of it
> > > so there is then only dynamic stuff). If somebody know how one can
> > > tell if a mem area was dynamiclly allocated or not then it's easy
> > > to solve. Othewise i really can't think of smthg clean.
> > 
> > Sure, i was also thinking of it yesterday.
> > The best would be to store somewhere (but where???) a flag telling the
> > config system that the given field (string) was allocated by the config
> > sys. It isn't really doable.
> 
> The question is should that be handled in layer2 or layer3. In G1 it's
> handled at layer3 but that not optimal bcs it's a tricky operation
> and it don't really belong there in fact (and make a layer3
> implementation harder).
> Layer2 implement string <-> C conversions, so it should also implement
> copy of the C values (and destroy/free). This is requiered when first
> creating a copy of the default struct bcs of the dynmamiclly allocated
> stuff for wich simple memcpy isn't enought.

yes

> So this 'protection' against freeing of static vars is required at
> layer2 imho. If we forbid double options (ie 2 options pointing
> to the same C var) for option type wich use dynamic mem then we
> can simply store a flag in the config_t struct wich indicate if
> the mem was allocated or not.

no, unfortunatelly you (config parser) can't store flags in config_t,
as it's shared between several instances (consider it read-only).

> If we allow double options on dynamic stuff i really can't think
> of a way to handle that at layer2 (beside smthg a la njamd ;)
:)

> On the other hand it's not a big limitation as double options
> are mostly used for flags (wich are not using dynamic mem) and
> to keep backward comp.
> 
> > The opposite approach is what you said: always duplicate (alloc+copy)
> > everything, so you can safely free() at the end.

I guess this is the only way, ie. always alloc+copy.

> > The 3rd approach is not free() at all, it isn't big memory leak :)
> If you consider a server app wich should run for months it is really
> an important problem.

why? i don't think that a server app keeps parsing config files for months :)
it will parse it once at startup.


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu