prussak@acsu.buffalo.edu (michal prussak) (01/03/91)
There is another problem for all you Xperts. 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, but XAllocColor never returns. Can anybody care to explain why could XAllocColor choose to hang? Is there any way around it? Michal Prussak
etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) (01/04/91)
In article <53361@eerie.acsu.Buffalo.EDU>, prussak@acsu.buffalo.edu (michal prussak) writes: |> |> There is another problem for all you Xperts. 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, |> but XAllocColor never returns. Can anybody care to explain |> why could XAllocColor choose to hang? Is there any way around it? |> |> Michal Prussak When you fork, you must close the connection to X in your child process, then reopen it. Then, to the X server, you are two completely different clients free to do whatever you desire. I am not sure of the supposed behavior of a connection after a process forks, but I assume it is undefined because of different implementations (i.e. VAX) -- Eric Taylor Baylor College of Medicine etaylor@wilkins.bcm.tmc.edu (713) 798-3776
mouse@larry.mcrcim.mcgill.EDU (01/05/91)
> 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
gildea@expo.lcs.mit.EDU (Stephen Gildea) (01/07/91)
Date: 3 Jan 91 16:35:42 GMT
From: etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor)
When you fork, you must close the connection
to X in your child process, then reopen it. Then, to the
X server, you are two completely different clients free to
do whatever you desire.
I am not sure of the supposed behavior of a connection
after a process forks, but I assume it is undefined because
of different implementations (i.e. VAX)
The R4 implementation of Xlib sets the close-on-fork bit for the
connection, so this problem never comes up.
< Stephengildea@expo.lcs.mit.EDU (Stephen Gildea) (01/08/91)
Whoops. I claimed the X descriptor was closed after a fork, but it actually doesn't get closed until an exec. Rereading the original posting again I see that program in question never execs, thus leaving itself (themselves?) two X descriptors. < Stephen