[Xcb] how should Xlib handle threads?

[Jamey Sharp]

The new Xlib-specific XCB API provides an accessor for XCB's I/O mutex
so that Xlib can use the same mutex as its display lock, and so Xlib can
overwrite XCB's normal mutex with a "recursive" or "counting" mutex.

pthread_mutex_t *XCBGetIOLock(XCBConnection *c)
{
    return &c->iolock;
}

Two problems: I really don't want Xlib hooked in that closely, and I
really don't want to be using recursive mutexes. What should I do?

The reason Xlib currently needs to share XCB's I/O lock is because
whenever the Display is locked, Xlib might queue a request and assign a
sequence number, and it does both things without getting XCB involved.
If at the same time another thread calls XCB directly to queue a request
and get a sequence number, then the client may believe both requests
have the same sequence number, which leads to an assertion failure soon
afterwards. As of today, I don't believe Xlib needs to execute anything
else atomically with respect to XCB.

I've contemplated two strategies so far. Both have... issues. I'm
certainly open to more alternatives.

First, we could try having Xlib maintain a virtual sequence number
stream and a map from virtual sequence numbers to the real ones that XCB
wound up assigning to the same requests. This entirely solves the
problem (I think), doesn't require any changes to XCB, reduces
contention between threads, and addresses XCB's occasional need to
spontaneously generate requests without Xlib's permission. On the other
hand it seems potentially hard to implement correctly, and the concept
of a purely fictional sequence number stream is just weird.

Or, we can implement a lock in XCB that protects only sequence-number
allocation and request queueing. As far as I can figure it, Xlib has to
be able to hold this lock while the Display is locked, and acquire it a
second time once Xlib has figured out it has bits to send. In other
words, this calls for essentially a recursive mutex. It can be
implemented as a condition-variable based pseudo-lock instead, but it's
pretty ugly however you do it. And it doesn't solve all the issues.

Any fix for this problem reduces the Xlib-specific APIs in XCB to a
single function, and that function might conceivably be useful to real
applications, which would be a really nice result.

So. Help?

--Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20051224/e9f88d6b/attachment.pgp