id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
2953,send_operation::perform does not consume buffer on would_block,Dustin Spicuzza <dustin@…>,chris_kohlhoff,"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. :) ",Bugs,closed,Boost 1.39.0,asio,Boost 1.38.0,Showstopper,fixed,vxworks asio,