----- Original Message ----- From: "Boris" <boris@gtemail.net> To: <boost@lists.boost.org>
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.