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

[Alban Bedel]

Hi Arpi,

on Thu, 15 May 2003 11:49:08 +0200 you wrote:

> 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.
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.
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.
> 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.
	Albeu