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

[Jeetu Golani]

Hi,

Thanks Solerman / Barton for writing in.

Barton, I'll read your paper and maybe that'll help crystalize the road ahead.

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

Is the threading mechanism what's chiefly bothering you? Would using the win32 
port of the pthreads library solve that?? 

Apart from threading the other relatively minor code changes would then become 

- the socket() function by default under win32 goes in Overlapped I/O, we have 
to stick to the synchronous mechanism already implemented in the library.

- The Scatter/Gather implementation within linux needs to be changed to the 
win32 equivalent.

However, if inspite of using win32 pthreads, threading behaves differently or 
there are other UNIX mechanisms in place here then yes I agree it'll probably 
be better to just take it all off and rewrite for win32 - that however seems 
quite a huge endeavour - would need a very very thorough understanding of 
every place in the code that this change would effect (probably the whole 
code).

Your views and clarifications on the above would be appreciated.

Bye for now


On Saturday 29 Mar 2008, Barton C Massey wrote:
> 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