-
Notifications
You must be signed in to change notification settings - Fork 665
Description
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.