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
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.
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).
Sean