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

From: Hugo Duncan (hugoduncan_at_[hidden])
Date: 2004-09-15 06:48:15

Spend a few days off line and you suddenly miss a whole conversation :-(
It's going to take a while to catch up...

Recent IOstreams discussion has indeed been very interesting,
espescially as I am finally getting round to implementing buffers
and filters for giallo (boost.sockets).  At the moment I am leaning
towards ACE style message buffer, using the apache filter idea
of flush/eos/eoc control (but trying to avoid any knowledge of
the underlying resource).

So where is giallo today (apart from being temporarily broken on gcc
due to mpl changes)?

i) Low level, platform header hiding, object based wrappers of
sockets, named pipes, select, and completion ports (and a POSIX aio
wrapper on linux that I have tried to get to work in many different
ways and failed so far).

ii) proactor and reactor interfaces, with policy based implementation,
provided by bridge classes to the low level completion port and select
wrappers above.

iii) 'event completion notification' style connector, acceptor and
connection classes for sockets and named pipes.
These classes combine a demultiplexer with a resource (socket, pipe, etc),
and can use a proactor or reactor demultiplexer interchangeably
(via template parameter).  The connection selects the synchronisation
mode (block, non-blocking, asynchronous) of the socket based
the demultiplexer.

The library is thread aware (can run multithreaded, will create
threads if asked to, uses threads to do asynchronous connect if not
natively supported, etc)

There is a streambuf implementation, but I have not found a way to
implement this without it degenerating to a thread per connection
model.

I feel quite strongly that the decision to implement connection,
connector and acceptor concepts with a single (in this case 'event
completion' style) notification interface, regardless of the
demultiplexer mechanism used, is very important, and can lead to a
stream/filter concept that is independent of demultiplexer, of
blocking/non-blocking/asynch mode and thus independent of the resource
used.