It does seem clear that we have a bug here; evidently signals do not wake up the reader, neither with readline nor without.
Andy On Sun 06 Sep 2015 19:18, Rob Browning <r...@defaultvalue.org> writes: > [If possible, please preserve the -forwarded address in any replies.] > > Reference: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765497 > > Panu Kalliokoski <panu.kallioko...@gmail.com> writes: > >> While playing with guile on my system, I discovered a weird anomaly >> which I could not reproduce on other systems running guile. If I >> install a signal handler for SIGALRM, it won't get called while guile is >> making an I/O system call. To demonstrate: >> >> [atehwa@karaihin ~/proj/psyk]$ guile >> guile> (alarm 2) >> 0 >> guile> Herätyskello >> [atehwa@karaihin ~/proj/psyk]$ guile >> guile> (sigaction SIGALRM (lambda (x) (display "now!") (newline))) >> (0 . 335544320) >> guile> (alarm 2) >> 0 >> guile> now a lot more than two seconds has passed, while I wrote this >> now! >> <unnamed port>: In expression now: >> <unnamed port>: Unbound variable: now >> ABORT: (unbound-variable) >> [...] >> >> As you can see, the signal handler gets called as soon as guile returns >> from read(2), already before calling (eval). >> >> I can't get to understand what causes this on my system, because another >> Debian system with exact same versions of guile-1.6, libc6 and >> libguile-ltdl-1 seems to work fine, and interrupts the read(2) call with >> the signal handler. > > This appears to still be the case with at least Debian's 2.0.11+1-10 > package, and setting the handler to something that doesn't perform IO > has the same effect (i.e. no alarm until you hit return): > > (sigaction SIGALRM (lambda (x) (exit 1))) > > Thanks
