RE: [boost] Re: AW: Re: AW: Sockets

From: Boris Schäling (boris_at_[hidden])
Date: 2002-11-25 18:56:53

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Hamish Mackenzie
> Sent: Monday, November 25, 2002 11:53 PM
> To: Boost mailing list
> Subject: RE: [boost] Re: AW: Re: AW: Sockets
>
>
> On Mon, 2002-11-25 at 20:57, Boris Schäling wrote:
> > > 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.
> >
>
> >From your example
>
>     void on_connect(communicator *c, int sock)

>       s = new stream(&mpx, this, sock, 0); // params:
> multiplexor, stream observer, socket descriptor, timeout value
>       s->writen("GET / HTTP/1.0\r\n\r\n");
>     }
>
> This looks like a blocking write to me. What if there was not enough
> room in the buffer for this writen (say I wanted to do an HTTP post
> including a 5GB file as the post data).  You need an on_write member to
> let you know when it is ok to do another write to the socket.

stream::writen() calls ::write() to send the data to the network. If
EWOULDBLOCK is returned the stream notifies the multiplexor to watch out for
the socket descriptor to become writeable. Whenever that happens the
multiplexor calls stream::write() (this one is different from
stream::writen()) which calls ::write() again. Your proposed on_write() and
the buffer exist in stream. Advantage: No action needs to be taken by the
application developer.

Boris