Re: [Boost-bugs] [Boost C++ Libraries] #3627: boost::asio::async_read() cannot be used with null_buffers()

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #3627: boost::asio::async_read() cannot be used with null_buffers()
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2010-01-12 14:16:28


#3627: boost::asio::async_read() cannot be used with null_buffers()
----------------------------------------------------------------+-----------
 Reporter: Dmitry Goncharov <dgoncharov@…> | Owner: chris_kohlhoff
     Type: Bugs | Status: new
Milestone: Boost 1.41.0 | Component: asio
  Version: Boost 1.40.0 | Severity: Regression
 Keywords: asio async_read null_buffers |
----------------------------------------------------------------+-----------
Changes (by jkp@…):

  * severity: Problem => Regression

Comment:

 I can also confirm that this is the case on OS X. The question I have is
 whether the change is intended? The new documentation seems to imply it
 is:

 {{{
 If the total size of all buffers in the sequence mb is 0, the asynchronous
 read operation shall complete immediately and pass 0 as the argument to
 the handler that specifies the number of bytes read.
 }}}

 Also, the changelist for 1.40.0 says the following:

 {{{
 Changed the buffered*_stream<> templates to treat 0-byte reads and writes
 as no-ops, to comply with the documented type requirements for
 SyncReadStream, AsyncReadStream, SyncWriteStream and AsyncWriteStream.
 }}}

 It's unclear what the intendended behaviour is from these two snippets.
 Certainly pre 1.40.0 you could call async_read with null_buffers and get a
 callback when some new data had arrived. This is extremely useful
 functionality, esp for code that has layered other streams on-top of the
 asio ones. Right now I have no way to check for data (async) without
 reading it off the socket.

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

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:02 UTC