Close on Drop Semantics
Noah-Kennedy opened this issue · comments
What do we think about our current semantics regarding close-on-drop?
I'm not sure if asynchronously pushing a close op is actually the best approach on drop. It complicates our code a surprising amount, as we need to be able to handle the case here where we drop outside of a runtime context, and thus we need to do a bit of working around this with try_submit and other hacks.
Personally, I think that we should change the semantics to synchronously close the fd (like tokio does) on drop and allow users to explicitly invoke an async close operation if they want to close an fd with uring.
How async should handle close on drop seems to be one of the questions that comes up again and again, even for tokio.
What drop are you referring to? Don't Op drops have to happen while still in the driver's block_on? At least normally. Do you mean when the user has to Op reference passed out of the context it was created in on purpose?
The uring driver gives us two other options, plus there is the final fallback to using std, as you say. The uring driver allows making a submission with no completion, and since 6.0, allows for a synchronous close.
There is one other complication. We should eventually support uring direct descriptors. When we drop one of those, if the ring exists, we have to use one of the ring's close mechanisms and if the uring has already been closed and there is no driver anymore, we can ignore the direct descriptor value because it won't represent anything and the kernel resource will have already been cleaned up when the uring interface was closed.
If we don't want to try and support pre 6.0 kernels the best we can, in other words, if we want to support 6.0+ kernels, we can say we'll only support direct descriptors for 6.0+ kernels and then we can use the nice synchronous close the uring interface gives us, or even the async close because it could mean one less system call.
So, with the off-runtime drop, I was referring to the semantics of, say, dropping a TcpListener.
So, with the off-runtime drop, I was referring to the semantics of, say, dropping a TcpListener.
We could plan on a sync/std close for something like that, when the fd is a file descriptor and reverting to a uring sync close when it is a uring direct descriptor.
We should probably create a dedicated issue for uring direct descriptor support.