[Xcb] XCB I/O mechanism - Native win32 port

[Jamey Sharp]

On Sun, Mar 30, 2008 at 12:51:44PM -0700, Barton C Massey wrote:
> There's a pretty sharp divide between the XCB top and bottom
> layers, and between pieces of the bottom layer.  I suspect
> you'd end up writing about 1000 lines of new code.

To be more precise, you should mostly be able to rewrite just
xcb_conn.c, xcb_util.c, xcb_in.c, and xcb_out.c--currently a total of
1,523 lines, some of which you could reuse--and then you should be done.
So Bart's estimate is probably about right.

On Sat, Mar 29, 2008 at 11:17:14AM -0700, Barton C Massey wrote:
> To be honest, for a Windows port I would probably just give
> up and use an extra thread or two to do I/O even for
> single-threaded programs.  This makes things incredibly
> easier; the user threads can post requests and receive
> responses via any old inter-thread communication mechanism,
> and the I/O threads can block when they need to.

I agree, at least for a first attempt.

On Sat, Mar 29, 2008 at 02:52:18PM +0530, Jeetu Golani wrote:
> I'm trying to understand the I/O mechanism used within XCB. As I
> understand it we seem to be using Non-blocking sockets with a
> synchronous i/o provided by the select function within xcb_conn_wait. 

What we're doing is generally referred to as just "non-blocking I/O" in
the Unix world. We arrange that our read and write calls will return
immediately, transferring as much data as they can without blocking. We
call select when we need to stop and ensure that some progress is made,
either toward delivering some requests or receiving some responses.

Any implementation of XCB, on any platform, will need to be able to
block sometimes, waiting for I/O. That's how xcb_wait_for_reply and
xcb_wait_for_event are specified to work. The select call is being used
here only to provide that required blocking.

> - Win32 has a concept of Overlapped I/O which allows for data to be
> copied directly into the user buffer directly as soon as it arrives
> into the lower layer. It signals a completion routine or an event
> automatically.
> (http://msdn2.microsoft.com/en-us/library/ms740086.aspx)

This is equivalent to what POSIX calls "asynchronous I/O", or AIO. It
seems to be a generally good idea (although as usual the Windows APIs
for it are awful) but the two implementations of it in Linux have
serious drawbacks.

I have this idea that we could get rid of some locks in XCB if we had
just the right AIO interface. I've been meaning to work out the details
and talk with the Linux AIO folks about it.

> - If using select is synchronous then how would we do a asynchronous
> i/o communication within linux. My limited understanding of the
> difference is that in one the application has to poll for socket state
> using select and in another as soon as the state changes the
> application is made aware using another thread and a notification
> mechanism. Is this correct? 

Not in general: AIO doesn't necessarily involve an extra thread. There's
usually no reason to use AIO and threads together, as far as I can tell.
Either you get an asynchronous callback in the same thread (POSIX calls
this "signals") or you have a way of waiting for completion of some or
all of your outstanding AIO operations.

Also, using the term "poll" here is misleading. The thread that calls
select goes to sleep until something happens that it was waiting for.
During that interval, it consumes no CPU time. "Polling" is generally
used to mean actively re-checking whether something is done yet. (I
think it's particularly unfortunate that the newer alternative to
"select" is actually named "poll"...)

> - Which would be more efficient with for Win32 Overlapped I/O or
> sticking to a mechanism with select?

I have no idea what might be efficient in Windows. Is anything? ;-)

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