Re: [boost] State of giallo, (sockets and demultiplexing)

From: Carlo Wood (carlo_at_[hidden])
Date: 2004-09-15 15:10:43

On Wed, Sep 15, 2004 at 02:37:06PM -0500, Aaron W. LaFramboise wrote:
> One concern I have is that this will not mesh well with other clients of
>  demultiplexors, such as process management or GUIs (network libraries
> and gui libraries are both notorious for monopolizing control flow).
> These things apparently need to be run in a separate thread.

Very good point.

> My primarily interest in demultiplexors is that they should be universal
> and unintrusive.  Its my feeling that once an elegant, universal, and
> free C++ demultiplexor exists, people will stop reimplementing it over
> and over, and spend more time writing their networking library or GUI.

I also think that we should concentrate on a *minimal* interface.
That is: just wrap whatever is now being handled by select/poll etc.

However, recently I realized that this is not possible
(after reading http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/wsarecv_2.asp)

The only way to provice a portable interface is by providing
a 'socket' class, that is explicitly a socket.  After all, in the
case of windows you will need to wrap WSARecv which is socket
specific.  Under UNIX you can ignore if handles are sockets or
files etc, and just treat everything as 'int' handles (making it
the responsibility of the user to make them non-blocking), but
that is not possible with the interface that windows provides.

You cannot make an interface for an abstraction 'class Handle'.
The reason for that is that too many details are important for
the demultiplexor when calling WSARecv, we cannot leave that to
the user.

I am afraid that we have no other option then to wrap the notions
of 'handles' completely, and instead provide an interface that
talks about specific 'devices' (sockets, files, pipes, timers etc.)

-- 
Carlo Wood <carlo_at_[hidden]>