[Xcb] [Socket handoff] Waiting forever...

Jamey Sharp jamey at minilop.net
Sun Jul 19 09:08:16 PDT 2009

On Sun, Jul 19, 2009 at 4:08 AM, Clemens Eisserer<linuxhippy at gmail.com> wrote:
> The pure-java backend now works as expected.
> I've stopped working on that stuff month ago, because I wasn't able to
> solve the hang problem and now with just a few modifications it works
> like a charme :)

Awesome! Where can we find the code and your thoughts on the process?

> It would be cool if the socket-handoff API could notify the
> socket-taker how many void-requests already have issued to be able to
> avoid the request after taking the socket.
> However I guess the overhead caused by the single request is noise.

Yeah, shipping an extra four bytes every once in a while isn't that
big a deal, since you don't have to wait for the reply, but it'd be
nice to not have to do it. Patches welcome :-) though if we change the
signature of xcb_take_socket the distros will probably axe-murder us
at this point.

XCB itself has enough information to put off the sync for a long time,
because every time a response arrives it can defer the sync longer. An
ideal solution would allow socket handoff users to do the same thing.

Also note that socket-handoff users don't have any way to tell XCB
whether the requests they're generating are void requests, so XCB has
to assume they might not produce a response whenever it decides
whether to insert a sync. Ideally, handoff callers that know whether
they're expecting a reply would have a way to tell XCB so, allowing
XCB to share that with other handoff users too. (Xlib can't easily
provide this information, so we can't require it of the caller, but an
API making it an optional optimization would be nice.)

I don't know what a good API to this would look like, frankly. Ideas, anyone?


More information about the Xcb mailing list