WaitGroup: spawn into an explicit Fiber::ExecutionContext

[ysbaddaden]

closes #15642

[yxhuvud]

One could perhaps take a step back and consider if the marriage between wait groups and contexts should live in either of these or if it should be an entity of its own. As a concept it is getting pretty close to the concept of nurseries in the structured concurrency way of thinking.

Where are we going, in the greater path toward more sophisticated ways of setting up execution?

[ysbaddaden]

IMO the nursery-like methods (.wait(&) and .spawn(&)) are the issue. Not the ability to specify a spawn context.

[BlobCodes]

One could perhaps take a step back and consider if the marriage between wait groups and contexts should live in either of these or if it should be an entity of its own. As a concept it is getting pretty close to the concept of nurseries in the structured concurrency way of thinking.

I think this is a valid concern.
For example, we could instead have a fiber-local value (just like Scheduler.current) which controls where new fibers are spawned into, and then build a block-based DSL around that:

ctx = Fiber::ExecutionContext::SingleThreaded.new(name: "test")

# sets the fiber-local spawn-context var
# ensures this is rolled back on block exit
ctx.with_override do
  spawn do
    puts "context: #{Scheduler.current.name}"
  end
end

This should be a more generic interface and avoid having to add explicit execution context support to every concurrency-related shard and class.

[ysbaddaden]

I'm closing. The idea to override the current spawn context is much better 👍