Am Sa., 1. Okt. 2022 um 20:56 Uhr schrieb John Cowan <[email protected]>: > > > > 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.
Let's keep this open for a few days. If we add `unwind-protect` to the Scheme language, we should get it right. > >> 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. Noted. >> >> 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. Here, these conditions are usually raised by the thread system. I meant whether the thread system should raise them continuably. I think this makes sense. >> >> 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). I will take a look. So far, I think that my amendment to your suggestion can still support the high-level approach. As an alternative, what about a `with-thread-runner` that takes a procedure and calls it with a procedure that is just a substitute for `make-thread`? This way, the primitive `make-thread` neither has to be modified: (with-thread-runner (lambda (make-local-thread) (define t (make-local-thread thunk)) ...))
