RE: [boost] Re: Re: Boost.Thread : IO multiplexing

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
>
>
<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