Boost logo

Boost :

From: scott (scottw_at_[hidden])
Date: 2004-01-27 21:51:30

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Jeremy
> Maitin-Shepard
> Sent: Wednesday, January 28, 2004 2:51 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Re: Re: Boost.Thread : IO multiplexing
> 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
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.


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