On Tue, 2002-11-26 at 17:12, Boris Schäling wrote: > > How does the multiplexor know what to pass to write the second time? > > The multiplexor doesn't know but the stream does. The multiplexor calls > stream::write() when the socket descriptor is writable. The stream calls > ::write() and sends all data which was saved in the stream's buffer because > of EWOULDBLOCK to the network. > > +-------------+ +--------------+ 1) +--------------+ > | multiplexor | 2) | stream |<-------| observer | > | |<-------| | | | > | | 3) | | | | > | |------->| | | | > +-------------+ +--------------+ +--------------+ > > 1) observer calls stream::writen() to send data. > 2) stream calls multiplexor::set_write() because of EWOULDBLOCK. > 3) multiplexor calls stream::write() when the socket descriptor is writable.
I don't think you have considered the reentrancy issues with this. If on_connect calls writen and writen simulates blocking (and waits for more than just writeable on the socket in question) then a second on_connect (or on_read) comes in then the first on_connect cannot complete until the second on has. > > Does the caller have to load the 5GB file into memory before passing it > > to the write? > > The caller may certainly write the file in chunks. Or did I misunderstand > your question? Now things start getting really messy. If on_connect calls writen more than once the second call may be delayed if the an event on a different socket (or a read event on the same socket comes in) is processed during the first call to writen. You may have plenty of bandwidth but slow client will cause a fast one to block. writen has two possible implementations 1) Wait for just on writeable on the socket in question. In which case it is indistinguishable from a blocking call. 2) Wait for and process other events to and get yourself into a reentrancy tangle. In my opinion the only correct implementation is 1. In which case writen is a blocking call. > > What if I want to send a live video stream? > > Good point. There is currently no UDP support in my library. Maybe traits > could be used to tell the stream to discard data that couldn't be written > immediately? I am not sure if anything else had to be changed for UDP? This is not the problem I am concerned about. I was trying to illustrate the problem (as discussed above) that arises when your output buffer is larger than the amount of information you have to write. -- Hamish Mackenzie <[EMAIL PROTECTED]> _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
