|
Boost : |
From: Boris Schäling (boris_at_[hidden])
Date: 2002-11-25 15:57:47
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Hamish Mackenzie
> Sent: Monday, November 25, 2002 2:43 AM
> To: Boost mailing list
> Subject: RE: [boost] Re: AW: Re: AW: Sockets
>
>
> [...]
> > I added
> >
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boo
> stSocket/M
> > ultiplexing to propose a design to support multiplexing. I am
> thankful for
> > any comments as I use this kind of library already and would be happy to
> > improve it.
>
> Looks good but am I correct in thinking it uses blocking writes to the
> socket? (no on_write). This is ok for some applications but would not
> work for sending large files or streaming live content.
The library uses non-blocking write. If a write returns EWOULDBLOCK the
library waits for the socket descriptor to be writable and then writes
again. The application developer does not need to take any action.
> How about instead of using on_read (and on_write) we use C++ iostream to
> process the data read from the socket and to produce the output to write
> to the socket.
>
> [...]
>
> It seems a bit odd at first (read_stream is an ostream). But the idea
> is that read_stream and write_stream would return non blocking streams
> (or at least streams less likely to block than the socket)
Maybe it is possible to wrap the stream in a std::istream/std::ostream-like
class. Then everyone can choose what he likes?
Boris
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk