forwarded 765497 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21424 thanks
[I used the wrong bug number (the old guile-1.6 clone) in the original forwarding. It should have been 765497, as in the headers above. Here's what I forwarded.] Reference: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D765497 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=C3=A4tyskello > [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 -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
