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

[Jamey Sharp]

Hi Clemens! I was just looking at your Bugzilla report on this:
	https://bugs.freedesktop.org/show_bug.cgi?id=22362

On Fri, Jan 02, 2009 at 06:51:32PM +0100, Clemens Eisserer wrote:
> I am using the new socket-handoff functionality to mix protocoll
> generated by XLib and some self-written protocol.
> I am experiencing strange problems, where XCB seems to wait forever on
> the server - like the stack-traces illustrate at the end of the email.

To summarize those, xcb_wait_for_reply hangs in select with no responses
forthcoming from the server. In my experience that always means the
client generated incorrect protocol (as you've noticed), or failed to
sync, which is what this looks like.

X-protocol responses have a 16-bit sequence number, but applications
frequently need to remember state about more than 65536 requests at a
time, so XCB widens the sequence number to 64 bits internally. To do
that, it must receive a response at least as often as every 65536
requests. That response could be an event or error--it doesn't have to
be a reply--but of course you can't count on receiving those.

When an app uses XCB's normal interface, rather than socket-handoff,
XCB can insert a sync request automatically as needed. In socket-handoff
clients, XCB can't safely insert requests ever, so the caller is
responsible for that.

The simplest approach you can take here is to issue a GetInputFocus
request immediately after xcb_take_socket, and then do it again every
64k requests that you issue. You *don't* need to wait for the reply
immediately; just make sure you pick up the reply eventually, or there
will be a memory leak. This is not optimal, but it is at least correct
and simple.

On Wed, Dec 17, 2008 at 01:53:02PM +0100, Clemens Eisserer wrote:
> 1.) I almost finished porting some C-code to pure java with
> self-written protocol generation (
> http://linuxhippy.blogspot.com/2008/12/almost-pure-java2d.html ).

That's really cool!

> 2.) How does xcb_writev works for unix-domain-sockets?

Quite well, thank you! :-)

> I tried to find information about writev but didn't find in-depth stuff.
> 
> - I somewhere read that there is a maximum per-writev size that may
> submitted, otherwise glibc will allocate a temporary buffer. How large
> is that size?

I think you're talking about this: "POSIX.1-2001 allows an
implementation to place a limit on the number of items that can be
passed in iov." See the NOTES section of writev(2) for more on that; but
it's a limit on number of entries in the iovec array, not total number
of bytes, and really I don't think you'll ever hit that limit.

> - Does xcb_writev copy or block or even both?

xcb_writev does not copy your buffer; it passes it directly to
writev(2). It can block if the server is not ready to read from your
socket and the kernel is out of space to buffer your writes. It doesn't
wait for any responses from the server or anything though, just for the
write to be queued at the kernel.

> I have a dual-core system but for now it seems when the x-server is
> processing commands the client has to wait and vice-versa - so only
> one core is fully loaded. When I used xlib-based code I often saw more
> than 100% load when i summed up both the xserver's and client's cpu
> consumption, but now 100% seems to be the upper limit. How is that
> implemented in xcb, are there any tricks which could help concurrency?

XCB *should* only be an improvement on Xlib in terms of concurrency.

I wonder if your output queue is *too* big? If you flush more often, the
X server can get started on the work you're requesting sooner. The only
reason to have an output queue at all is because system calls are
expensive and you want to do fewer of them.

If that doesn't help, something like `strace -T` may tell you what
syscalls are keeping your process waiting.

> Thanks again for the handoff-functionality. Its so simple but extremly
> flexible - exactly what I was looking for :)

That's good to hear! We sure hoped it would be useful.

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/20090624/b634d487/attachment.pgp