Boost logo

Boost :

From: kensai_at_[hidden]
Date: 2001-07-30 17:37:17

--- In boost_at_y..., williamkempf_at_h... wrote:
> --- In boost_at_y..., "Greg Colvin" <greg_at_c...> wrote:
> > From: <williamkempf_at_h...>
> > > ...
> > > * The "must be portable" requirement may prove more than
> 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
> > > 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
> > > that do not rely on Win32 specific WndProc mechanisms. (I never
> > > understood why I/O was tied to a GUI object in Win32
> > > 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,
> 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.
> > 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
> to check for data" I mentioned. In fact, this can be done with
> () 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
> for socket descriptors.

The closest match in Windows would be to use i/o completion ports.
It's inextricably linked to threading, but completion routines work
for both socket and file operations (and perhaps others as well --
you can explicitly signal an operation as complete) and are quite
similar to poll(). In addition, they remove the 64 event limitation
of WSAWaitForMultipleEvents.

Still, this is a far cry from BSD sockets. Settling on a portable
interface might be difficult... but if the library is buit on select
() no Windows programmers may use it (I probably wouldn't).


Boost list run by bdawes at, gregod at, cpdaniel at, john at