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".
[...]