-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org]On Behalf Of Jeremy Maitin-Shepard Sent: Wednesday, January 28, 2004 2:51 PM To: boost@lists.boost.org 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.
you entire message sounded right to me. would make the following suggestion as a "way out". agree with the "[difficult] to unify waiting for async". maybe its not required? does an application truly want to "unify" at the level of sockets events and filesystem I/O completions? my suggestion is that unification should be occuring at a higher level and therefore it would be valid to cope with sockets in one thread, I/O completion in another thread,... if (quick and ugly example) a (async) socket is open to an FTP server, is the application interested in the next FD_READ or the next complete, SMTP-conformant, message, e.g. "user"? don't know if i've explained myself very well but in my mind at least this absolves you of any guilt as you narrow your focus onto the "select" family. cheers, scott