Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!bloom-beacon!ti-csl.csc.ti.COM!ekberg
From: ekberg@ti-csl.csc.ti.COM
Newsgroups: comp.windows.x
Subject: Keeping track of color allocation
Message-ID: <9008291845.AA09734@osage.csc.ti.com>
Date: 29 Aug 90 18:45:09 GMT
References: <801@auto-trol.UUCP>
Sender: ekberg@osage.csc.ti.com
Organization: The Internet
Lines: 27

Martin Brunecky writes:
 >  When I allocate my color, I never know if the pixel returned to me is a
 >  "brand new one", or just a "clone" of a pixel already alocated from MY
 >  CLIENT by some widget (string-to-pixel converter) or something else.  Thus,
 >  issuing XFreeColor on such a pixel, I am running a BIG risk that I will
 >  free a pixel that is still in use.
 >
 >  I can use writeable color cells - those will be unique to my allocation
 >  request. But with this approach I can lock-out other clients, leaving them
 >  with a very small palette of read-only color cells. I don't want to take
 >  this approach either.

It appears that you were looking at an R3 or older version of the X11 protocol
specification.  A change made to the R4 protocol specification says the
following with regards to the FreeColors request;

	Similarly, a read-only entry is not actually freed until it has been
	freed by all clients, and if a client allocates the same read-only
	entry multiple times, it must free the entry that many times before the
	entry is actually freed.

This means that your client, at multiple levels, can allocate the same pixel
more than once.  When it comes time to freeing the pixel, each level freeing
that pixel will work as expected.  There is no need to shadow the FreeColors
request to handle this case.

  -- tom (aisle C-4Q), ekberg@csc.ti.com