Re: [patch] cache color info for remote X sessions [Was: Emacs 21/X11 generating unbelieveable network traffic]

[Stefan Monnier]

> re-entrant manner, I should add a mutex lock to the cache.  Is this really a
> possibility, or were you just expressing a distaste for non-re-entrant code
> on principle?

It was on principle.  It saves you from having to think about
whether or not re-entrance can happen.

> > By the way, is the cached answer always the same as the one we would have
> > goten without the cache ?  
> For AllocColor, yes.  For XQueryColor{,s}, no.

For AllocColor ?
How come ?  Can't Emacs dealloc the color and re-allocate it again and
get a different result (because the color cell was allocated to some other
color in the mean time) ?

> > Can/should we invalidate the cache sometimes to avoid/reduce those
> > problems ?
> "should" -> yes.  "Can" is trickier.  In order for an old cache entry to be
> "wrong", the X server will have to allocate a colormap entry once, then
> dealloc it, then allocate another color in that space.  Which really comes
> down to the X server having very few colormap entries and an app that asks
> for a lot.  I don't think emacs will be running into this problem soon
> (although, testing with xpms/pngs might be instructive here).

As someone whose colormap is full about 95% of the time, I can
assure you that tose things happen ;-)
Maybe we can flush the cache whenever Emacs deallocates a color
(that shouldn't happen too often, right?).  BTW shouldn't we cache
DeAllocColor as well since the server normally keeps a counter
and each AllocColor should have a matching DeAllocColor ?


        Stefan