Re: [Boost-bugs] [Boost C++ Libraries] #8967: Spurious zero bytes written and eof notifications highlight ASIO IOCP issues

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #8967: Spurious zero bytes written and eof notifications highlight ASIO IOCP issues
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2013-08-10 11:37:19

#8967: Spurious zero bytes written and eof notifications highlight ASIO IOCP
issues
-------------------------+-------------------------------------------------
  Reporter:              |      Owner:  chris_kohlhoff
  simoncperkins@…        |     Status:  new
      Type:  Bugs        |  Component:  asio
 Milestone:  To Be       |   Severity:  Problem
  Determined             |   Keywords:  eof GetQueuedCompletionStatus
   Version:  Boost       |  WSARecv WSASend overlapped
  1.54.0                 |
Resolution:              |
-------------------------+-------------------------------------------------

Comment (by simoncperkins@…):

 Thanks for your comment. I don't believe that handling the notification
 directly without on_pending is a problem for the following reasons:

 1) The existing I/O operation has already completed (even though the API
 may not have returned) if another thread picks up the notification using
 GetQueueCompletionStatus().

 2) None of the multi-threaded samples I looked at on MSDN worry about
 calling WSARecv/WSASend in a notification handler even though the
 originating API may not have returned.

 3) The MSDN docs for WSARecv explicitly state that this is acceptable for
 completion handlers:

 *** "The WSARecv function using overlapped I/O can be called from within
 the completion routine of a previous WSARecv, WSARecvFrom, WSASend or
 WSASendTo function. For a given socket, I/O completion routines will not
 be nested. This permits time-sensitive data transmissions to occur
 entirely within a preemptive context." ***

 The IOCP / GetQueueCompletionStatus mechanism is just a way of running the
 completion handler on a pool thread.

 It's not clear to me how the on_pending function should work. When you
 call PostQueuedCompletionStatus it doesn't even care if you supply an
 overlapped structure (google for 'The parameters to
 PostQueuedCompletionStatus are not interpreted' ). It can be read by
 GetQueueedCompletionStatus independently of whether the I/O has completed.
 You would have to use a call to GetOverlappedResult to wait for the
 results.

 It looks to me like the code around on_pending and
 win_iocp_io_service::do_one has been written assuming that the
 notification from on_pending will be delivered when the I/O is complete.
 That's not the case - it just delivers the parameter values from
 PostQueuedCompletionStatus when the next thread returns from
 GetQueueedCompletionStatus. It does not look at the I/O operation
 associated with the overlapped structure.

 Although, my patch contains more changes I think it has the following
 benefits:

 1) It results in less code in the ASIO IOCP implementation

 2) During normal operations PostQueuedCompletionStatus is only called when
 an I/O immediately fails. I believe this could have a performance benefit.
 Currently, it is called for every non-failing I/O operation effectively
 doubling the number of notifications that have to be handled by the
 service threads.

 3) The code is closer to the structure of the IOCP samples that Microsoft
 provides

 4) I believe the on_pending code has a problem because it's notification
 may be dequeued before the I/O has completed

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