Have you considered separating the concept of cancellation from fibers?
Not at this time, mostly because cancellation is a deep topic with a lot of consequences that will require building up confidence. In addition, Threads already have an interrupt status to support the concept of thread interruption (similar concept but also different, the main one being that a Fiber’s cancel status cannot be reset).
Every I/O operation should have a timeout
Decomposing deadlines or timeout into timeouts for specific I/O operations is really hard to get right (your blog on this topic is really good). The approach in the prototype has a withDeadline method to enter a scope with a deadline. If the deadline expires before the scope has exited when all fibers scheduled in the scope are cancelled. If fibers are parked in blocking I/O operations then they will throw an exception and terminate. It’s possible that code catches the exception and doesn’t terminate quickly but there is nothing we can do about that. There are slew of discussion poinst around this of course and we will hopefully have more on this on the Loom wiki soon.
Have you considered binding scopes more tightly to the creating frame?
We will likely be iterating on the API for some time. But yes, initial prototypes had methods that took something like Consumer<FiberScope> and overloads to deal with tasks that return a value and of course checked exceptions. The approach leads to a lot capturing of effectively final local variables in the enclosing scope.
What do you think about auto-propagation? Is your plan to always require manual propagation?
We have experimented with propagation of exceptions but it can be argued that a bit “too magic”, esp. if the exception (and stack trace) is far removed from the code that scheduled the fiber. Our current approach requires an explicit join to collect results or exceptions.
Trio also has a concept of shielding you might find interesting. Interestingly, we only use it in very rare cases. … Is shielding the only way for users to manage/track cancellation points, or will there be other mechanisms as well?
Yes, I agree its usage will be rare but it is important for some cleanup operations. Asynchronous close is one example where closing a resource that is in use by another thread or fiber requires coordination that needs to be immune to cancellation to avoid leaving the resource in in consistent state.
Cancellation in the current prototype is cooperative, a fiber can check for cancellation at any time with Fiber.cancelled(). I hope to be able to point to something on Loom wiki soon that explains this in more detail.