Re: [boost] Re: sockets /network programming Requirements

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-07-30 15:56:13

From: <williamkempf_at_[hidden]>
> --- In boost_at_y..., "Greg Colvin" <greg_at_c...> wrote:
> > From: <williamkempf_at_h...>
> > > ...
> > > * 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.
> 
> 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.

Right.  In our case there isn't much mileage in keeping the
implementations uniform, and I suspect that will be true for
Boost as well.

The Solaris man pages prefer poll() over select(), so we don't
use select() on Unix.

On Windows we need to wait on sockets, pipes, and files, so again
we don't use select().  We use WaitForMultipleObjects() with the
appropriate events.

We don't use callback routines, but instead we have a low-level
call that polls for available I/O that is integrated into the
thread scheduler.  Before blocking on I/O a thread registers
an event to wait on with the thread scheduler.  I'm not sure if
such a design makes sense for Boost, but it might.