[Boost-bugs] [Boost C++ Libraries] #2953: send_operation::perform does not consume buffer on would_block

Subject: [Boost-bugs] [Boost C++ Libraries] #2953: send_operation::perform does not consume buffer on would_block
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2009-04-17 07:21:12

#2953: send_operation::perform does not consume buffer on would_block
----------------------------------------------------------+-----------------
 Reporter:  Dustin Spicuzza <dustin_at_[hidden]>  |       Owner:  chris_kohlhoff
     Type:  Bugs                                          |      Status:  new           
Milestone:  Boost 1.39.0                                  |   Component:  asio          
  Version:  Boost 1.38.0                                  |    Severity:  Showstopper   
 Keywords:  vxworks asio                                  |  
----------------------------------------------------------+-----------------
 On at least some platforms (in particular, vxWorks), apparently when
 sendmsg is called it will transfer part of the buffer and set errno to
 EWOULDBLOCK.

 At boost/asio/detail/reactive_socket_service.hpp:651, the if statement
 statement should be changed to consume the buffer if there were bytes
 written. Like so:

 {{{
 if (ec == boost::asio::error::would_block
     || ec == boost::asio::error::try_again)
 {
     if (bytes > 0) buffers_.consume(bytes);
     return false;
 }
 }}}

 I was not able to get my Windows machine (using BOOST_ASIO_DISABLE_IOCP)
 to return a would_block error, so I cannot say whether this is true for
 all platforms (can you think of a way to possibly provoke this behavior on
 another platform?). It seems like it would be a safe enough change to make
 however.

 Do you know if this is standard behavior, or is vxWorks breaking the rules
 here (though, its network stack is based off the BSD 4.4 stack so this
 probably affects BSD platforms also).

 I would imagine that this happens for other calls that check for
 would_block in the same file (there are a number of them), so those may
 need to be changed also.

 I was using the asio http server example 1 to provoke this bug. The
 resulting behavior is that the server keeps transmitting the same data
 buffer over and over and over...  amusingly, I had modified the server to
 use persistent connections, so it would transmit hundreds of megabytes
 when a 50kb file was requested. I changed to the unmodified example code
 and I got the same behavior.

 There are a number of other things that asio needs to compile/run on
 vxWorks properly, but I'll file a separate bug for those once I clean that
 up. :)

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/2953>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.