Am Sa., 1. Okt. 2022 um 20:56 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Sat, Oct 1, 2022 at 9:14 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> 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))
    ...))