Thanks for taking a closer look at the recent changes!

Am Mo., 14. Nov. 2022 um 20:05 Uhr schrieb Shiro Kawai <xxxxxx@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 <xxxxxx@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.