On 2-Dec-05, at 12:46 PM, Russ Cox wrote:
I've got it working except for the dreaded X11-is-single-
threaded race condition.
Can you explain the race?
Not well - it's an internal X11 thing. As I understand it the server
gets hosed when receiving messages on separate connections referring
to the same objects - it appears to track a message ID and gets
confused when it receives more pieces of a transaction without having
come to the end of a previous one. It typically shows up in multi-
threaded apps, for which Xlib provides a locking mechanism. Any non-
atomic transaction can fail that way, and Xsync() calls get confused.
What winds up happening in my space is that I communicate the window-
id through an environment variable, and libdraw grabs that ID if it
exists. X copes with that fine unless someone else winds up making
calls on that window at the same time; for example the 9term that was
in the window resizing along with the acme that currently has the
window.
The better way is probably to use Xnest's code to make a virtual X
server within a window and serve that through libdraw. But what an
ugly, monstrous mass of code to deal with. But then all X apps would
just work. But I'm happy with just my plan9/libdraw apps working :-)
Is it inter-process but still one program? What are the specific
code pieces that need to be interlocked? The multi-process
X apps in p9p each use their own display to avoid most of
the races.
It is multi-program: acme "on top of" 9term, for example; any X call
that takes a window id needs to be protected or else out of sequence
errors can happen.
Can you describe what you mean by "their own display"?
Paul
