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 <[email protected]>: > > 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 > <[email protected]> wrote: >> >> Am Mo., 14. Nov. 2022 um 20:01 Uhr schrieb John Cowan <[email protected]>: >> > >> > >> > >> > On Thu, Nov 10, 2022 at 3:16 PM Marc Nieper-Wißkirchen >> > <[email protected]> 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. >> > >> >>
