Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think.com!snorkelwacker.mit.edu!bloom-beacon!dont-send-mail-to-path-lines
From: mouse@larry.mcrcim.mcgill.EDU
Newsgroups: comp.windows.x
Subject: Re:  Allocating Colors in a forked process
Message-ID: <9101050804.AA10879@Larry.McRCIM.McGill.EDU>
Date: 5 Jan 91 08:04:23 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 48

> In my Xtoolkit program I have a callback function.  This function
> forks in the middle, where the parent returns, while the child keeps
> on doing some work.  The child calls XAllocColor at some point,

Regardless of toolkits or anything else, when a process with an X
connection forks, at most one of the resulting processes can do
anything with the connection.  Unless you *like* random protocol
violations, that is....

There are multiple problems with trying to do this.

One problem is that both data streams involved, the client-to-server
one and the server-to-client one, are being mangled.  The
client-to-server stream has pieces of requests from the two processes
intermixed in a more or less random order, depending on precisely when
the clients called write() and how much got written at a time (which in
turn depends on internal buffer sizes and such).  The server-to-client
stream is being read by both processes, and is being chopped into bits
depending, again, on buffer sizes and race conditions; these bits are
being distributed some to each process, where they are concatenated and
treated as "the" server-to-client stream.  No wonder Xlib gets
confused.

As if that weren't enough, the sequence numbers and resource ID
allocation numbers will be completely confused.  This is significant;
it means that you can't simply take the trouble to ensure that only one
process is trying to do X stuff at a time.  Even if the data stream
contention mentioned above is resolved, X still has sequence numbers
(and similar things) that will break badly with two processes trying to
use the same connection.

None of this depends on what widget set or toolkit you use.  Anything
built on top of Xlib will have this problem.  (Indeed, it would require
great care to build a substitute for Xlib that didn't have similar
problems.)

The only safe thing to do is for one of the processes (it doesn't
matter which one) to close its copy of the connection.  To avoid
flushing buffered data twice or stealing pieces of the event stream, I
would suggest simply closing the connection with
close(XConnectionNumber(dpy)) rather than using XCloseDisplay(dpy).  If
both processes need to do X things, one (or both) must close its copy
of the connection and open a new one.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu