Page History

...

The main benefit of structured concurrency is abstraction.  A caller of a method that is invoked to do a task should not care if the method decomposes the task and schedules a million fibers. When the method completes, any fibers scheduled by the method should have terminated.

Background Further reading:

    Nathaniel J. Smith: Notes on structured concurrency, or: Go statement considered harmful

...

scope1 is entered with a deadline that is now + 10s. It schedules a fiber in scope2 and cannot exit to scope1 until the fiber terminates. If the deadline expires in the meantime then the fiber will be cancelled and the thread/fiber will throw CancelledException(“Deadline expired”) when existing scope1. If the inner scope had a deadline that was further into the future that the deadline then the deadline for the outer scope will expire first.

In addition to withDeadline, FiberScope also defines withTimeout to enter a scope with a timeout, expressed as a java.time.Duration. If the timeout expires before thread/fiber exits the scope then all fibers scheduled in the scope are cancelled.

Further reading:

    Nathaniel J. Smith: Timeouts and cancellation for humans

Termination queues

Fibers communicate to other fibers or threads using queues or other mechanisms. They may also return a result, retrieved by invoking the Fiber’s join method. As a convenience when scheduling fibers in a FiberScope, the API defines schedule methods that specify a termination queue. The Fiber that the fiber is queued to the termination queue when it terminates. The following examples example schedules fibers to executes tasks that return Strings. The fibers are queued to a termination queue then they terminate. The results are obtained by invoking the Fiber::join method.

...

• 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. An alternative API that has also been prototyped

  Code Block
  language java
  FiberScope.cancellable(scope -> { ... });

  
  The downside with this approach is that checked exceptions are awkward to deal with. It also requires capturing of effectively final variables in the enclosing scope. The API surface is also larger as there are different consumer variants to allow for a return value (or none).
  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 For now, the API requires an explicit join to obtain an exception thrown by a fiber.

• At this time, a FiberScope object need to be guarded to avoid leaking to a callee that closes the scope. Another concern is the fibers method to obtain a stream of the fibers executing in the scope. The main use-cases for the fibers method is cancellation and debugging, both of these need to be re-examined.

...