[Xcb] Help with external socket handling and xcb

[Carlo Wood]

Hello!

I have an application that has no idle loop. Everything is event driven.
It has wonderful support for sockets (any fds) with at its core my own
calls to the epoll API (I use linux).

In the ideal case, xcb wouldn't mess with sockets reading or writing
at all and just do the protocol part. In that case I need it to tell
me what it wants to write to the X server (and I'll do the buffering
of that). As well as when it expects a reply from the server (so I
can start monitoring the socket for input) and have a function that
I can call to feed it received data. I can even do that after decoding
the data a bit (if you tell me how) so that the provided data is a
complete (contiguous) message (this would be the fastest way).

Unfortunately, not many libraries that provide protocol handling
provide such an API - most of them insist on also handling the socket
side of things; and as far as I can tell xcb is like that too.

Using xcb_get_file_descriptor I can start monitoring it for input
(aka, a function is called whenever the socket is readable).
At this point I NEED a substantial amount of data to be read
from the socket (preferably everything, so that epoll won't report
it being readable again). I understand that this is possible by
calling xcb_poll_for_event until it returns NULL. Again: I'd rather
do the reading and buffering of the data myself and then feed
that to xcb to decode it; but this will work... or does it?

Because I assume that xcb internally will keep reading the socket
until that returns that there is no data left to read. And in order
for that not to be blocking, the fd has to be non-blocking (which
is obviously what I normally want).

However, doesn't there need to be data written to the socket too?
When does that happen? With the current set up I can't monitor the
socket to see if it writable because it is ALWAYS writable. I can
only do this when xcb tells me (through a callback) that it NEEDS
me to monitor the socket because it has something to write (and
also tells me when I can stop monitoring the fd again).

So, since it doesn't do that (as far as I know), it will have to
make sure that every time it has something to write, it writes
ALL of it before returning to my code... and that sounds very
blocking. How can this ever work reliable with a non-blocking
fd? Or is xcb just calling write in a loop until it wrote everything
it has to write (also when write returns EAGAIN)?

If anyone can give me pointers, or maybe tell me about a part of
the API that I missed that is suitable for this, that would be great!

Regards,
Carlo Wood