On 1/02/2018 05:39, Stian Zeljko Vrba wrote:
So is the following possible:
1. Another read operation is started, but that one completes immediately because data is ready on the pipe. I.e., async_read_some immediately posts the completion handler. 2. close() has nothing to cancel, but closes the socket. 3. The handler posted in 1 is executed, it goes to initiate another read, and that read finds the pipe closed, returning errc::invalid_handle.
No, because you don't call close() directly, you post() a method that calls close(), which cannot execute before #3 unless either the operation is still pending or you have already started a new operation that is now pending.
Even if async_read_some does *not* post the handler immediately but just initiates the I/O, this I/O can complete immediately and cannot be canceled on the OS-level. Thus attempted cancellation by close() will be a noop, the read handler will get an OK status and proceed to use the closed handle...
No, because the close hasn't actually happened yet, it's still sitting in the queue. The queue itself is OS-managed, so the moment the operation completes it will push the completion handler to the queue. It doesn't require intervention from ASIO code.