On Sat, Oct 1, 2022 at 9:14 AM Marc Nieper-Wißkirchen <[email protected]> wrote:
> (define-syntax unwind-protect > (syntax-rules () > ((unwind-protect protected-form cleanup-form) > (call-with-continuation-barrier > (lambda () > (dynamic-wind > (lambda () (values)) > (lambda () protected-form) > (lambda () cleanup-form))))))) > > Is this close to what you have in mind? > LGTM, though I have not checked to see how well it matches the (single-threaded) CLHS definition. There is a de facto standardization of OS threads for CL, but none for green threads that I can find. If I were to design my own iterator protocol, I would make the iterator > procedure take two continuation procedures, a success procedure that would > be invoked on the iterator's tail and the next value, and a failure thunk. > This is the most direct translation from the abstract iterator semantics. > All other protocols can be simply derived: > Nice. I hope to see a SRFI of this type. > Make `&thread` inherit from `&serious`, not `&error`, and raise some > conditions continuably. > > What do you think? > Well, it's always up to the raiser whether to use raise or raise-continuably, not the definer of conditions. But it would be fair enough to advertise that this is a supported thing to do. > I don't see this as a problem. More than one thread-runner would wait for > the same thread to terminate, which would pose no problem. > Okay. > (This works well because the creation and the start of threads are >>> separated.) When the thread runner is called with no argument, we could >>> make it unregister and return an arbitrary thread it holds. >>> >> >> This defeats the scoping for which thread-runners were devised. However, >> the concerns could be separated by providing (register-thread thread-runner >> thread), which fails if the thread is already registered, as well as >> (with-thread-runner proc). >> > > I don't see a problem here, but maybe I don't understand. > I think we are talking past one another. You are describing a lower-level construct, which is good in itself, that I would call a thread-holder: it holds threads and allows you to wait until an arbitrary thread completes. But a thread-runner is intended as an object for *structuring* concurrent computation. I recommend < https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/#go-statement-considered-harmful> (the earlier part of the paper is a rehash of "Go to considered harmful", which I assume you have read). >
