Cancellation hooks on async IO traits

[withoutboats]

With completion based IO, we need a way to deregister interest in the IO when it is cancelled. Setting aside buffer management issues (which have been discussed at length elsewhere), there is this fundamental problem: somewhere in your program, a Waker will be stored so that the task can be re-awoken on completion. If you cancel your interest in the IO event, the waker hangs around and there will be a spurious wake up.

Integrating buffer management makes this even more of a problem, since the kernel needs to hold not only the waker but also the buffer the IO operates on. When we cancel our future, we'd like to set it up so that instead of waking our task spuriously, the completion just cleans up any resources it needed to hold for the kernel.

All of this works fine as a Drop implementation on a future. However, the concept of the futures-io async IO traits is that there is no future that owns the IO object, but rather you implement a type with poll_* methods that can be called by consecutive IO operations.

What would be needed to make this work well in the APIs I've explored is a hook in AsyncRead and AsyncWrite for indicating that the interest in this op has been cancelled. The destructors for futures like Read and Write can call these hooks. Then, the IO object can process the cancellation and clean up its state, preparing the completion and allowing new operations to be performed on the IO object.

[kazuki0824]

@withoutboats I agree with your idea, and I'm also thinking of making AsyncRead/AsyncWrite or related io methods, actually performing kind of data transfer, abortable.

In my opinion, simply merging an existing Abortable functionality with them may 1. cause inconvenience from redundance, 2. sacrifice performance(due to atomic ops), so we have to carefully design the structure when it comes to abortable IO traits. Thus, I'd like you to explain more of your ideas to me, such as what " completion based IO" is, how the Waker should be behaved , and so on. I'm working on it in #2507 , and would love to benefit from your thoughts!