|
Boost : |
From: Greg Colvin (greg_at_[hidden])
Date: 2001-07-30 14:53:25
From: <williamkempf_at_[hidden]>
> ...
> * The "must be portable" requirement may prove more than vexing. Unix
> programmers rely heavily on select(), while Windows programmers can
> only make very limited use of this and rely almost completely on
> asynchronous routines not available to Unix programmers. The
> simplest way to insure portability is to support only blocking i/o
> with very limited ability to check for available data, but this can
> severely complicate coding. A possibly better solution is to provide
> a callback mechanism similar to the asynchronous routines in Win32
> that do not rely on Win32 specific WndProc mechanisms. (I never
> understood why I/O was tied to a GUI object in Win32 asynchronous
> routines.) Such an interface could be coded portably using threads on
> any platform, though the design will be much more complicated.
> ...
It is possible to paper over these Unix/Windows differences, since most
all the available java sockets implemenations do so.
In our implementation of the java socket classes we use poll() rather
than select() on Unix, and WaitForMultipleObjects() on Windows. We
don't wait for a Windows GUI object, but instead for the hEvent that we associate with the socket with WSAEventSelect(). The code
belongs to
Oracle, so I can't post it, but there are other more open java
implementations one could study.
One catch is that our I/O polling implementation is tightly coupled
with our thread scheduling, socket I/O, and file I/O code. I don't
know if we want such coupling in a Boost sockets library, but it does
have advantages.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk