Re: [boost] Asynchronous I/O

From: Scott Woods (scottw_at_[hidden])
Date: 2005-03-17 16:51:47

----- Original Message -----
From: "Boris" <boris_at_[hidden]>
To: <boost_at_[hidden]>

> 1) Signal-Driven I/O
> SIGIO is sent to a process whenever something happens with the socket. As
> there are too many things happening with a TCP socket the signal is
> generated too often and "signal-driven I/O is next to useless with a TCP
> socket" (W. Richard Stevens in his network bible). As there is just one
> signal handler per signal it shouldn't be used in a library anyway.
>

[snip lovely research]

>
> Now who has an idea how the asynchronous C++ library should look like? ;)
>

Good background and a little daunting. Happy to see your new subject; the
change
highlights the fact that issues around async sockets/networking have much
broader
scope.

I think its appropriate to mention that typical software development is not
async in
nature, i.e. the picture is perhaps worse as there is a plethora of issues
arising from the
variety of OS async mechanisms and the global body of software developers
does
its best to express everything in procedural/OO terms. These two trains have
to
collide somewhere.

Maybe I can describe this another way. It would seem logical (to me :-) to
target an
async I/O library that integrated cleanly with A. Hubers FSM work, with the
view of
implementing socket management with a Huber FSM. This follows from the
belief that
async software == state machine software. But what portion of Boosters would
find
an FSM-based "Boost socket" palatable? There is clearly a learning curve
involved
around Andrea's work and it has been contentious enough, without throwing
sockets
into the brew.

This might all sound a bit gloomy but really its just creating the
challenge; "can we write
a portable asynchronous delivery mechanism?"  (good one Don).

Cheers.