-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org]On Behalf Of Sean Kelly Sent: Thursday, January 29, 2004 6:18 AM To: Boost mailing list Subject: Re: [boost] Re: Re: Boost.Thread : IO multiplexing
<snip>
As far as asynchronous read/write (on sockets) handling, I do not believe it is possible to unify waiting for asynchronous completion with the type of polling described above, at least on POSIX platforms. It would be possible to create a portable library for waiting (only) for asynchronous completion of a read or write. One issue with the POSIX asynchronous i/o interface is that it does not, AFAIK, support reading or writing asynchronous out-of-band data on TCP sockets. I suppose though that since out-of-band data is not used all that often, this is less of an issue; still, it is a reason for people to use polling rather than asynchronous read/write, particularly since in a network server, it would be necessary to have at least one thread waiting to accept new clients.
Windows has asynch listen but it's kind of annoying to use. I've always used one or more threads for the task--overhead is minimal since they're basically always blocking. Beyond that, I think the i/o layer should be a thread pool that does i/o processing exclusively. Since it's a thread pool some synchronization is already required and extending execution into the rest of the application code seems like an invitatation to trouble.
One issue with this design is that the i/o layer should likely only pass complete messages back to the appliction code, which implies the need for a protocol layer. And if encryption is a possibility then the model would need to allow the protocol layer to initiate its own responses for the negotiation process. The risk here is that application code could leak into the i/o code.
Any suggestions? It would be nice to get a different perspective on all of this.
tried to say the same thing in a previous mail. agree totally. if your going to mention encryption then you may as well go all out and also worry about session and presentation (which include encryption). only allude to the network model (ISO) cos its such a convenient and complete reference. doesnt mean that the entire beast has to be tackled; or even should be. by the time you have a generic environment that supports 1 or more "multiplexing threads" that exchange "complete messages" then it starts to take on the appearance of an app framework. cheers.