Re: gtk+ and gtk-engines slow

[Jeff Garzik <jgarzik pobox com>]

On Sat, 23 Jan 1999, Jeff Garzik wrote:
> The solution was to create one big buffer, and manage it cooperatively
> using semaphores and mutexes.  In essense, you create your own malloc
> which grabs a buffer of shared memory.  It was a cyclical buffer, so
> that messages (or pixmaps in this case) expired when they were
> overwritten by the newest incoming message -- or pixmap in this case.
> 
> The one downside to this approach (which I didn't have to worry about in
> my experiment NNTP server) is that if refcounting breaks down, you have
> to manually clean the IPC shm segment list. 

You'll have to pardon me, it was a while since I built that server.  :)

Ignore what I said about refcounting breaking down.  Since the buffer is
cyclical, lost refcounts will got ignored in the next cycle.  (that's
why you style the cycle number)

	Jeff