On Jun 29, 2010, at 2:24 AM, Keith Packard wrote:
On Tue, 29 Jun 2010 02:18:31 +0200, Mario Kleiner
<[email protected]> wrote:
What i assume but didn't check is that xlib doesn't have a problem
with getting replies out of sequence
The X protocol is purely sequential -- you can't execute requests
out of
order (and queuing replies is part of the request execution). In
particular, no X library would ever deal with replies being
returned out
of order; they count on the sequence number from the X server being
monotonic.
Ok, thanks. That makes live for multi-threaded clients a bit more
difficult if they want to use the new extensions, because they would
need to maintain multiple x connections, one for each thread, to
circumvent this. I guess then xcb doesn't handle this either?
Then i think the idea of multiple wait queues doesn't allow to get
rid of IgnoreClient(), but we will still need those wait queues in
addition to IgnoreClient() to handle multiple blocking requests for
one drawable from different clients / x-connections correctly.
The current code assumes exactly one client / x-connection per
drawable. I think if we have multiple threads accessing the drawable
over separate connections then the current IgnoreClient() method will
not work and we will end up with undefined behaviour for some of the
new dri2 protocol requests.
E.g., what should work according to the spec is that i have multiple
threads, each of them using its own dedicated x-connection to perform
a glXWaitForSbcOML() or glXWaitForMscOML() or glXSwapBuffers()/
glXSwapBuffersMscOML() call for the same drawable and getting its
request retired when the corresponding event happens. Currently
random stuff would happen if i tried this. If i remember correctly
the first thread making a request would be correctly handled and all
other threads would hang forever - their requests would disappear
into nirvana.
Anyway, this is a separate issue from IgnoreClient(), so i'll discuss
it separately with Jesse.
Another question: If i have separate x-connections, e.g., one for
each drawable and each connection has an opengl rendering context
attached to the drawable, then i assume these context still can share
state (display lists, shaders, texture objects, fbo's etc.), right?
thanks,
-mario
*********************************************************************
Mario Kleiner
Max Planck Institute for Biological Cybernetics
Spemannstr. 38
72076 Tuebingen
Germany
e-mail: [email protected]
office: +49 (0)7071/601-1623
fax: +49 (0)7071/601-616
www: http://www.kyb.tuebingen.mpg.de/~kleinerm
*********************************************************************
"For a successful technology, reality must take precedence
over public relations, for Nature cannot be fooled."
(Richard Feynman)
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
