Thanks, John.

As mentioned in my post from Nov 11th, I believe that the API of SRFI
226 is rich enough to implement a "user space" version of thread
runners.  Thus I want to move them to a yet-to-be-written separate
SRFI (that may also include some other high-level (convenience)
procedures/syntax).

Am Sa., 18. Feb. 2023 um 04:00 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
> I believe I understand now, and I think the answer is that with-thread-runner should accept an optional static timeout.  When this timeout happens, all threads in the runner are forced to exit on a timeout exception.  I do not see a use case for non-static timeouts.
>
> On Mon, Nov 14, 2022 at 2:06 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>> Am Mo., 14. Nov. 2022 um 20:01 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>> >
>> >
>> >
>> > On Thu, Nov 10, 2022 at 3:16 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>> >
>> >> 1. John, you suggested adding an optional timeout parameter to
>> >> `with-thread-runner'.  It may be better to add an optional thunk
>> >> argument that is called when the thread runner procedure returns. The
>> >> thunk is supposed to return a timeout.
>> >
>> >
>> > I don't understand this at all.  First of all, I don't know what you mean by a thread-runner procedure.  There is the procedure `with-thread-runner`, which returns when its threads have terminated normally or abnormally.  It passes a thread-runner object (a container for threads) to its body thunk, whose purpose is to start threads and register them with the thread-runner object.  So with-thread-runner actually needs to wait until its registered threads terminate *and* the body thunk (which runs in the same thread as with-thread-runner) has returned.
>>
>> I meant the procedure PROC that is passed to `with-thread-runner`:
>>
>> (with-thread-runner PROC) where PROC is something like (lambda (t-r-o) ...).
>>
>> When it returns, the threads that are still running need to be waited
>> for.  When we add a timeout parameter, shall it be fixed at the
>> beginning or dynamically determined?  In the latter case, a possible
>> signature of with-thread-runner could be
>>
>> (with-thread-runner PROC THUNK-RETURNING-TIMEOUT)
>>
>> >
>> >>
>> >> 2. If a timeout happens, what should be the return values for the
>> >> threads that didn't finish in time? Or no particular return value and
>> >> let the following thread-join! with a timeout of 0 detect it?
>> >
>> >
>> > They should be terminated with a timeout exception.  No thread-join is needed, because that's what thread-runners do.
>> >
>> >>