Thanks for taking a closer look at the recent changes! Am Mo., 14. Nov. 2022 um 20:05 Uhr schrieb Shiro Kawai <shiro.ka...@gmail.com>: > > POSIX does not require pthread_cond_wait to be interrupted by a signal; It > does call a signal handler but can resume waiting, instead of returning to > the caller as most other system calls. That makes implementing Schemel-evel > thread-interrupt! difficult.
SRFI 226 makes no guarantees when thread-interrupt! actually interrupts. > > In Gauche, a Unix signal handler just records the signal delivery in a > per-thread VM, and Scheme-level handler will be invoked later at the "safe" > point of the VM. If a thread is waiting on pthread_cont_wait, however, it > may not return after recording the signal delivery and may wait indefinitely. > > One possible strategy is that we always use pthread_cont_timedwait and let it > timeout periodically to poll if a signal is delivered. It can be complicated > if the Scheme program also sets a timeout, but doable. I wonder what other > implementers think. Couldn't a thread store the POSIX condition variable it currently waits on in a thread local? Thread-interrupt! will then just signal this condition variable. Marc > > > On Fri, Nov 11, 2022 at 7:19 AM Marc Nieper-Wißkirchen > <marc.nie...@gmail.com> wrote: >> >> I have documented thread-interrupt! in 5.14.6. >> >> Thread-exit! is now renamed to thread-stop!. >> >> I hope that only editorial changes remain before we finalize this.
