5 ms·

I don't get it. What's the ideal scenario here? That going to the sleep branch of the select should cancel the accept? Will cancelling the accept terminate any

I don't get it. What's the ideal scenario here? That going to the sleep branch of the select should cancel the accept? Will cancelling the accept terminate any already-accepted connections? Shouldn't it be delayed instead? Shouldn't newly accepted connections be dropped only if the listener is dropped, rather than when the listener.accept() future is dropped? If listener.accept() is dropped, the queue should be with the listener object, and thus the event should still be available in that queue on the next listener.accept(). This seems more like a bug with the runtime than anything.

ethegwo 2y ago
the ideal scenario is like cancellable io provide by monoio, I write an example of this in the blog: https://github.com/ethe/io-uring-is-not-cancellation-safe/blob/cancelable-io/src/main.rs#L47 https://github.com/ethe/io-uring-is-not-cancellation-safe/bl... . However, it has lots of limitation, and do not have a perfect way to do this at the moment.
- whytevuhuni 2y ago
  That's an implementation detail. What's the user-facing behavior? What should happen with mistakenly-accepted connections? Even the blog admits that cancellation of any kind, is racing with the kernel which might complete the accept request anyway. Even if you call `.cancel()`, the queue might have an accepted connection FD in it. Even if it doesn't, it might do by the time the kernel acknowledges the cancellation. So you now have a mistakenly-accepted connection. What do you do with it? Drop it? That seems like the wrong answer, whoever writes a loop like the one in the blog will definitely not expect some of the connections mysteriously being dropped.
  - whytevuhuni 2y ago
    Okay, looks like withoutboats gave the answer to this in another thread [1], and that seems like the right answer. The accept() future being dropped must not result in any cancellation of any kind, unless the listener itself is also dropped. This is an implementation issue with monoio that just needs more polishing. And given how hard io_uring is to get right, monoio should be given that time before being chosen to be used in production for anything. [1] https://news.ycombinator.com/item?id=41994308 https://news.ycombinator.com/item?id=41994308
  - ethegwo 2y ago
    I don't think the operation that completes after cancellation failed is "mistakenly-accepted," it should be handled in the normal way, but I admit that there are lots of people don't agree that

ethegwo 2y ago

the ideal scenario is like cancellable io provide by monoio, I write an example of this in the blog: https://github.com/ethe/io-uring-is-not-cancellation-safe/blob/cancelable-io/src/main.rs#L47 https://github.com/ethe/io-uring-is-not-cancellation-safe/bl... . However, it has lots of limitation, and do not have a perfect way to do this at the moment.

whytevuhuni 2y ago
That's an implementation detail. What's the user-facing behavior? What should happen with mistakenly-accepted connections? Even the blog admits that cancellation of any kind, is racing with the kernel which might complete the accept request anyway. Even if you call `.cancel()`, the queue might have an accepted connection FD in it. Even if it doesn't, it might do by the time the kernel acknowledges the cancellation. So you now have a mistakenly-accepted connection. What do you do with it? Drop it? That seems like the wrong answer, whoever writes a loop like the one in the blog will definitely not expect some of the connections mysteriously being dropped.
- whytevuhuni 2y ago
  Okay, looks like withoutboats gave the answer to this in another thread [1], and that seems like the right answer. The accept() future being dropped must not result in any cancellation of any kind, unless the listener itself is also dropped. This is an implementation issue with monoio that just needs more polishing. And given how hard io_uring is to get right, monoio should be given that time before being chosen to be used in production for anything. [1] https://news.ycombinator.com/item?id=41994308 https://news.ycombinator.com/item?id=41994308
- ethegwo 2y ago
  I don't think the operation that completes after cancellation failed is "mistakenly-accepted," it should be handled in the normal way, but I admit that there are lots of people don't agree that