Boost logo

Boost :

From: scott (scottw_at_[hidden])
Date: 2004-01-28 13:46:10


> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk