...

There is no support yet for making context available to all fibers scheduled in the scope. InheritedThreadLocals can be used in the mean-time.

Issues/Discussion/TBD

• The current FiberScope API is a prototype API to demonstrate and explore concepts. For now, FiberScope is an AutoCloseable and so encourages the use of the try-with-resources construct. The advantages of this approach is that it plays well with checked exceptions and it is easy to access variables in the enclosing scope. The downside is lack of guaranteed cleanup (a ThreadDeath, OOME, or other resource issues may abort the execution of the finally block and close). It is also possible to misuse, e.g. leak the scope to a callee that closes it explicitly. It has been suggested that the API should define methods to enter a scope and take a Consumer that provides the scope to the action. This has been prototyped, just a bit awkward to deal with checked exceptions and it can require a lot of capturing of effectively final variables in the enclosing scope. It also requires a slightly larger API

...

• to deal with consumer that return a value or don’t return a value. We will re-evaluate this once we have more experience with the concepts.

• The Python Trio library has automatic propagation of errors (to ensure that errors are never lost).  An approximate equivalent was prototyped with FiberScope so that a fiber terminating with an exception propagates the exception to the thread/fiber that scheduled it. With nesting, the exception might propagate up a tree. A concern with the approach is that it’s “too magic”. So for now, the API requires an explicit join to obtain an exception thrown by a fiber.