RE: [boost] Re: Re: SocketSetConcept (fd_set wrapper)

From: Darryl Green (Darryl.Green_at_[hidden])
Date: 2002-11-26 02:56:31

> From: Hamish Mackenzie [mailto:hamish_at_[hidden]]
> > I'll change the name to file_descriptor_set.  The reason I had left
it
> > as socket_set was that I was not sure how to mix SOCKET and files
> > on windows - but htat looks to be easy from your code....
> 
> Ah, I should have pointed out that I have only used
file_descriptor_set
> on sockets.  I don't know if will work with win32 files.

There are (or were last time I looked) problems with select on files on
windows. Can't recall the details. However, there are ways and means of
working around this - I think cygwin has.
 
> Also Hu Xinwei pointed out that fd_set should probably be an
> implementation detail.  Check out this for instance...
> http://www.xmailserver.org/linux-patches/nio-improve.html

We elected not to expose the fd set in our library. While we have not
yet done so we wanted to be able to plug-in alternative "select-like"
handlers such as /dev/poll and/or whatever worked on other platforms.
The select (or whatever) lives in an event dispatcher (one per thread).
We have active file descriptors (AFDs), 1 for read, 1 for write and 1
for except) which are merely thin facades sharing an underlying file
descriptor holder (FDH) which is hidden from the user and provides most
of the machinery around the real file descriptor. The AFD interface for
async use is very simple/generic - just the ability to register a
parameterless boost::function to be called when the AFD is ready. The
base AFD class provides c-style read, write methods and the intent is
that higher level code bind this lot together to provide appropriate
interfaces eg. streambufs. There is also a method for
registering/deregistering the AFDs interest in receiving ready events
without having to create/destroy AFDs or deregister handler functions
(obviously passed this down to the event dispatcher to update the fd
set).
 
> 
> Can we stick with SocketSetConcept and hide the fd_set completely.
> 
> I like the idea of a boost event system that would allow waiting on
> several types of events in a portable way.  But I don't know if it is
> feasible. See..
> 
> http://aspn.activestate.com/ASPN/Mail/Message/boost/1448661

I think it is, up to a point. How cross platform that point will be
could be the real issue, though we have found that a huge variety of
interfaces aren't really necessary. Some simple message passing method
to allow things like async timers and shutdown requests can easily be
extended. It is likely that almost any platform could support at least
some form of "file" which can have a byte (makes partial writes
impossible) written to it by any thread wishing to send an event to the
reader of that "file". Once woken via this simple interface the reader
can use whatever communication and synchronisation methods are
appropriate (using the byte as a hint) to obtain additional information.
 
> 
> If we can't have something like that then separating sockets and files
> makes sense.  Perhaps though we could add a socket_event_source_set
(or
> nicer name) that would work as I described event_source_set but would
> only support socket_read_event_source, socket_write_event_source and
> socket_except_event_source.  It could be implemented using three
> socket_sets and select.

Are you describing what we called an event dispatcher?

Regards
Darryl Green.