Re: gtk+ and gtk-engines slow

[raster redhat com]

On 23 Jan, Jeff Garzik scribbled:
->  
->  
->  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)

no but if clients exit wihtout clenaing up their shm ataches things get
ugly:(

->  
->  	Jeff
->  
->  

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenment   http://www.rasterman.com/

              \|/ ____ \|/  For those of you unaware. This face here is in fact
	      "@'/ ,. \@"   a Linux Kernel Error Message.
	      /_| \__/ |_\
		 \__U_/