Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen 27 Oct 2022 06:01 UTC

Am Fr., 30. Sept. 2022 um 21:15 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

[...]

> 5. I recommend the addition of a simple thread-runner facility.  A thread-runner is an opaque object with which threads can be registered by passing it as an optional argument to `make-thread!`.  The procedure `with-thread-runner` takes a procedure *proc* and invokes it with a newly allocated thread-runner.  The purpose of `with-thread-runner` is to keep the forking and joining of threads within the lexical scope of *proc*, so as to avoid thread-level spaghetti code.
>
> When *proc* returns, `with-thread-runner` waits for all registered threads to terminate normally or abnormally, and then returns a list of the threads in arbitrary order. It is then possible to use `thread-wait` on any of these threads to extract their results.  `With-thread-runner` should perhaps take a second, optional, argument which is a timeout.
>
> Acknowledgement: the Python library Trio.

I am still thinking about this, and what's the best way to realize
`with-thread-runner'.  What do you mean by "within the lexical scope
of *proc*"?  Do you mean the dynamic extent?  Should *proc* be wrapped
in an unwind-protect not allowing to reenter it?

I am also still hoping for a reply from Marc in the discussion about
"weak threads".

[...]