Re: [boost] Re: behond IOStreams

From: Carlo Wood (carlo_at_[hidden])
Date: 2004-09-13 07:59:33

On Sun, Sep 12, 2004 at 09:53:49PM -0400, David Abrahams wrote:
> Carlo Wood <carlo_at_[hidden]> writes:
> 
> > Each of these Sources will need to be handled by the
> > Operating System; for example if they are sockets.
> 
> It isn't obvious to me that all Sources need to be handled by the OS.
> I can easily imagine sources that are not OS services.  Or were you
> saying something else?

Ok, let me rephrase that.  Forget IOStreams and Sources for a moment ;).
I think there is a need for a (minimal) event demultiplexor library.
Basically something like libevent, that works on most UNIX OS and
is build around the best demultiplexing system call available on a
given OS, but hiding the different interface used (select, poll, epoll,
kqueue and more).  As a result of using libevent it is possible to
write an application that runs very efficient on both linux (epoll
when the kernel is recent enough and select or poll when compiling
libevent on an older system) and FreeBSD (kqueue), without that the
user is bothered with these differences between those interfaces.

What is missing in libevent is support for windows; it depends on
the fact that all devices on all UNIX have the same interface:

int fd = open_and_or_create_some_device(initialization);
ioctl(fd, more_initialization);
special_function(fd, more_stuff);

And that works on *all* UNIX OS for all devices in a sufficient
portable way (although you still need #ifdef-ed code for certain
things like setting filedescriptors to non-blocking (comes in
basically two flavours, SYSV and BSD).

The only thing that libevent therefore needs to support is the actual
demultiplexing of events on 'fd' (an 'int' for EVERY device) and
a timeout with at least milisecond resolution.

This interface is obviously not portable enough for boost.
Even if we only consider adding support for windows a major
change of the available interface is needed.  In order to
provide a portable interface that includes non-UNIX OS
it is necessary to include the concept of certain common
Device classes (ie, files, sockets, pipes) and provide an
abstraction for them as well.

Ok, back to IOStreams.

Now note that many of those devices can serve as a source or sink of
a stream of data.  This indicates that they will both, be a notion
within this multiplexor library but also in the IOStream library
(as either a possible Source or Sink).  That doesn't mean that
EVERY Source or Sink is an OS handled device.  But it does mean
that we need to keep in mind that users will likely want to use
'Devices' that can be used with both, boost.multiplexor AND
boost.iostreams in an easy and intuitive way.

-- 
Carlo Wood <carlo_at_[hidden]>