It’s unclear based on the paper whether the idea is that other blocking operations (besides condition variables) would have to be enhanced to support cancellation tokens. That could require massive changes. But without these additional changes, cancellation tokens will not be very useful because interruption will not unblock operations.
1 Like
In this case, b/c we are explicitly spawning threads, we are talking about synchronous programming. You can spin-up an event loop inside the thread, of course, and then you'll need to somehow plug the is_canceled call into the select/epoll that drives the loop.
As soon as the read call returns (either timeout or gets some data),
Unfortunately, that might not always be possible, the "file" is some kind of IPC mechanism, where the blocking is indefinite. For example, in Cargo we need to play some tricks with signals to wake up a read which blocks on a pipe: jobserver-rs/src/lib.rs at cddd571ab014a66c52728c9599ded17d5f838927 · rust-lang/jobserver-rs · GitHub
1 Like
Basically, if you have a method/function that takes a Cancellation Token as a parameter it is an implicit contract that that method/function will not make arbitrarily long blocking calls and will check the cancellation token in a reasonable time-frame. What this means in practice is every call made inside such a method/function does one of:
- takes and honors the cancellation token
- is "fast" and non-blocking
- has a reasonable time-out if blocking with retry capability in a loop where the cancellation token can be checked
Again, a nice improvement over C# for example would be if Rust could statically ensure that one of those 3 things is always happening on every call.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.