On Sep 6, 9:00 am, Simon King <simon.k...@uni-jena.de> wrote: > [Errno 4] Interrupted system call
OK, here's at least a snippet that produces the relevant error message: sage: import signal sage: import sys sage: def handler(a,b): ....: print "signal handled" ....: sage: signal.signal(signal.SIGALRM,handler) 0 sage: signal.alarm(2) 0 sage: sys.stdin.read() #just wait and let it block ... signal handled ... IOError: [Errno 4] Interrupted system call sage: In the above example, the SIGALRM arrives during a blocking system call. The handler executes and "returns". However, the system call knows that a signal was handled and instead of continuing, it exits with an EINTR. The code in "p_iter_fork" tries to avoid further influence from set alarms by executing a signal.signal(signal.SIGALRM,signal.SIG_IGN) That is NOT the default SIGALRM handler! SIG_DFL just aborts the program. One should defuse pending alarms by descheduling them: signal.alarm(0) (there can be at most one alarm pending per process). It seems that on linux, if SIG_IGN is set as a handler on SIGALRM, the signal really does get ignored by system calls. No EINTR, but just a continued block. Perhaps that on BSD, SIG_IGN doesn't quite have that effect? It might help to actually clear alarms by "signal.alarm(0)" rather than relying on SIG_IGN handling them as if they didn't happen (it's certainly cleaner that way). Plus the whole code in p_iter_fork might just restore the old SIGALRM handler rather than leaving it to SIG_IGN. The child from a fork should have any alarms cleared and its signal handlers reset so I don't think the SIGALRMs are affecting any of the subprocesses. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
