[Xcb] deadlock with xlib/xcb

[Josh Triplett]

Jamey Sharp wrote:
> Christoph and I spent a couple hours on IRC today and we believe we
> fixed this deadlock.
[snip detailed analysis]

Awesome; nice work.

> Christoph asked why we have this awful Xlib-specific lock inside XCB
> anyway. In the X protocol, a request sent to the server does not contain
> its sequence number--the client and server both count how many requests
> have gone by, instead. So allocating a sequence number and allocating
> output buffer space must happen together, atomically.
> 
> Xlib allocates its sequence numbers in a macro, GetReq (and variations),
> which we can't change because its definition is published in XlibInt.h,
> which makes it effectively public API for Xlib. That means that when
> Xlib's "Display" structure is locked with LockDisplay, it must have the
> currently valid sequence number in it, and that sequence number must
> remain valid until UnlockDisplay.
> 
> So in Xlib/XCB, LockDisplay asks XCB what the current sequence number
> is, and locks out XCB from allocating sequence numbers or buffer space
> until UnlockDisplay. In other words, the xlib-xcb lock is to prevent XCB
> from allocating new sequence numbers or output buffer space while Xlib
> *might* be trying to do the same thing. This was the smallest API I
> could come up with to make Xlib work.
> 
> 
> I had another plan that eliminates all this complexity, but nobody would
> let me get away with it. If Xlib is allowed to lie to its clients about
> what sequence numbers were on the wire then this is a lot simpler. :-)
> Xlib can allocate contiguous sequence numbers, and then internally keep
> a mapping of what they actually were when they get sent later, and map
> events and such back to the fake numbers as they return. That means that
> Xlib-using code can free-run alongside XCB-using code without locks or
> serialization, and that XCB doesn't need any special Xlib-specific API.
> But keithp and Bart vetoed that plan. I think Keith was opposed to
> letting Xlib lie about sequence numbers, and Bart says he's opposed to
> adding the complexity of the mapping to Xlib.

This plan would have some other advantages; for instance, it would allow
higher-level APIs that for some reason require NextRequest (such as GTK+)
to work.  However, those APIs should really just get ported to the XCB
asynchronous cookie model.

- Josh Triplett


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20071029/0571b96b/attachment.pgp