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

[Barton C Massey]

Heh. The I/O mechanism in XCB is incredibly confusing,
because of the attempt to be thread-transparent while doing
thread multiplexing without an extra thread.  See my paper
"X Meets Z" linked from the XCB website for an explanation
of what I've always meant that we should implement here.
What we've actually implemented is, as far as I know,
totally undocumented, embarassingly enough.  We should
either fix it or explain it.

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.

Porting the existing I/O mechanism to Windows seems very
hard to me, as this mechanism takes full advantage of UNIX
semantics.

	Bart

In message <200803291452.18301.jeetu.golani at gmail.com> you wrote:
> As I've mentioned in the list I'm attempting to port the
> XCB library to Win32.  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.

> - 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)

> - We seem to be using a select function within
> xcb_conn_wait to poll for the state of the socket which in
> mind means we're using non-blocking sockets with a
> synchronous i/o.

> - 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?

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

> I admittedly have little understanding of the above and
> would appreciate if someone could shed light on what would
> be the preferred mechanism for this library.

> Bye for now