Boost logo

Boost :

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
highlights the fact that issues around async sockets/networking have much

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
its best to express everything in procedural/OO terms. These two trains have
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
an FSM-based "Boost socket" palatable? There is clearly a learning curve
around Andrea's work and it has been contentious enough, without throwing
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).


Boost list run by bdawes at, gregod at, cpdaniel at, john at