On 3/30/07, leon zadorin <leonleon77@gmail.com> wrote:
> be trying to touch the same Display. This offers a unique
> synchronisiation capability that cannot be implemented by Xlib clients
> alone - because there is no way for the client to say where the
> internal Xlib's thread of execution is... and the best way (IMHO) to

just a minor clarification - when I typed "internal Xlib's thread of
execution"  I did not mean to imply that Xlib starts its own internal
threads, but rather that in multithreaded app, there is a thread which
runs Xlib/Xevents loop (e.g. the thread on which "main" is running)
and there are other threads which do not know wher the thread which
runs XLib happens to be: inside some XLib function which alters
Display or not, so the fine-grained locking cannot be achieved simply
by putting an "application-initilased" mutex locks around the "main"
and other threads... which would appear to be a reason for the whole
XLockDisplay feature (for XLib do its own lock/unlock around sections
of the code which alter Display)... that is all - hmmm this English
thing is rather hard :-)