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

[Jamey Sharp]

On Wed, Jul 01, 2009 at 11:52:21AM -0400, Clemens Eisserer wrote:
> Thanks a lot for looking at that stuff :)

Sure!

> ... when I issue a getInputFocus request with self-generated protocol,
> how can I consume the reply in native code?

Same as for any other request you issue this way: call either
xcb_wait_for_reply or xcb_poll_for_reply, with the sequence number of
the request you issued. Just make darn sure that you've passed the
request to xcb_writev before you try to wait for the reply or your app
will probably hang. :-)

Notably, waiting for a reply should be independent of who owns the
socket at the moment (I think; haven't looked at this recently) so it
doesn't matter if Xlib has called xcb_take_socket before you wait for
the reply.

> To have a simple playground I also modified my c-testcase ...

>        int ret = xcb_take_socket(con, &return_socket, &flags, 0, &sent);
> ...
>        for(requests = 0; requests < 500; requests++) {
>          written += fillRect(picture, &buffer[written]);
> 	 written += getInputFocus(&buffer[written]);
>        }
> ...
>        xcb_writev(con, &vect, 1, requests);

Aren't you writing 1000 requests here and telling XCB there were 500? I
think that explains both your failures.

That aside, debugging tips for future reference:

> aborts either with:
> > handoff: xcb_io.c:242: process_responses: Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <=
> > 0)' failed.

On an assertion like this, it might help if you reproduce the problem
with gdb attached, get a stack trace, and print these values:
- dpy->last_request_read
- dpy->request
- dpy->xcb->connection->in.request_read
- dpy->xcb->connection->out.request_written

You might include the other variables in connection->in and
connection->out that are named request* as well, for completeness.

> or the XServer resets the connection:
> > XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server "localhost:0.0"
> >      after 130277 requests (65146 known processed) with 1 events remaining.

Those numbers are suspicious. 130277-65146 is 65131, which looks like
about the moment that Xlib would try to sync. Possibly the first time
the client read from the socket after writing a ton of requests?

Also, errno 11, EAGAIN, probably shouldn't have been fatal. That
probably means we're misinterpreting an error status somewhere in either
XCB or Xlib. :-( Again, it might help to attach gdb and get a stack
trace when _XIOError is called.

> However using wireshark the protocol I generated at least *seemed*
> valid (wireshark was able to decode it ;) ).

Always a good sign! :-)

> Last question, why does XEventsQueued cause a socket-takeback of the
> native side? The application I use frequently calls XEventQueued, and
> it seems like socket-handoff ping-pong is taking place :-/ Any idea
> howto work arround that issue?

XEventsQueued needs to cause any responses from the server to be read,
so it calls process_responses. That in turn needs the Display to have
recent sequence numbers, which it can only get reliably by taking
ownership of the socket. At least, I think that's why that works that
way. Frankly I don't remember now and I'm too sleepy to find out.

I'm not sure there's much we can do about that. Of course, you'll get
much better results if you convert all the event handling to use XCB
directly instead of Xlib. :-) That's something several people on this
list can help with, if you feel up for that.

BTW, it is true that the hand-coded protocol bits in your test app are
frightening. :-) It doesn't matter much how one-off test programs are
implemented, but I hope you'll use something more structured for your
real code. :-)

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