shared memory and styles
Michal Vitecek (M.Vitecek@sh.cvut.cz)
Mon, 8 Feb 1999 13:02:26 +0100
in my opinion this can't be done with help of shared memory because such
a feature is not implemented on all un*ces afaik. i think that only
afterstep or some kind of configuration module would open a two-way pipe
to the modules and feed them with correct data from already preparsed
configuration. this would ease the parsing part in every module (they'd
be sure the data is correct) and when the configuration 'feeding' is
done, the configuration module finishes thus freeing some memory. of
course, on loading a new theme (including the modules ilke the pager,
winlist etc) the configuration module would be started again and all
would go round...
this is just how i think it could be programmed independently on
platform.
> Doug Alcorn wrote:
> >
> > Sasha_Vasko@osca.state.mo.us writes:
> >
> > >
> > > The disadvantage of course is that we'll need to break compatibility with
> > > old
> > > configuration files.
> > >
> > Another disadvantage is that the Style database (aka new look file)
> > will have to be read by each module at startup time. Could we have
> > AfterStep cache the styles in memory somewhere? This would be a poor
> > use of memory, but would cause startup to be faster. If all of the
> > styles were in memory, then the individual modules could just read
> > from that shared memory location. Updating the look would then be
>
> That makes very good sense. I'm not sure how to implement this -
> but
> that definately will be better to store Styles in shared memory
> pool.
>
> > (__) Doug Alcorn
> Sasha
--
fuf
------------------------------ na IRC -------------------------------------
BillGates [bgates@www.microsoft.com] has joined #LINUX
...
mode/#linux [+b BillGates!*@*] by DoDad
BillGates was kicked off #linux by DoDad (banned: We see enough of Bill
Gates already.)