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

[Alban Bedel]

Hi Arpi,

on Thu, 15 May 2003 15:15:19 +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.
> 
> 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).

Well here i'm strictly talking about options appling to a 'static'
vars, not those who describe some struct fields. So they shouldn't
be shared (or am i missing smthg ?). Options wich describe struct
fields don't have this problem as in this case the only thing that
we'll is copying the 'default' struct.
But you'r right that config_t should be considered 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.
Seems so sadly.

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

Well an option wich is related to a 'static' var may be setted an
unlimited number of time, for example betwen each file.
	Albeu