Date: 2001-07-30 15:22:35
--- In boost_at_y..., "Greg Colvin" <greg_at_c...> wrote:
> From: <williamkempf_at_h...>
> > ...
> > * The "must be portable" requirement may prove more than vexing.
> > programmers rely heavily on select(), while Windows programmers
> > 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
> > severely complicate coding. A possibly better solution is to
> > 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
> > any platform, though the design will be much more complicated.
> > ...
> It is possible to paper over these Unix/Windows differences, since
> all the available java sockets implemenations do so.
> In our implementation of the java socket classes we use poll()
> 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.
I guess I wasn't overly specific. This is the "very limited ability
to check for data" I mentioned. In fact, this can be done with select
() on Win32 to keep the implementation more uniform across
platforms. The drawbacks are that this select() mechanism is valid
only for sockets. Unix users mix socket, file, pipe and keyboard
descriptors in a single call to select() to wait for multiple I/O
events, but the Win32 select (and the WSAEventSelect) will only work
for socket descriptors.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk