alarm() doesn't work for Cython code

[sagetrac-alexc]

The following code does not work as intended (I imagine), i.e. it does not interrupt the computation after 3 seconds.

#!/usr/bin/python -tt

from sage.all import *
import time

def main():
  alarm(3)
  try:
    EllipticCurve([123456, 789011]).rank()
    #time.sleep(5) #code works as intended if the above command is replaced with this
  except KeyboardInterrupt:
    print 'Took too long'

# This is the standard boilerplate that calls the main() function.
if __name__ == '__main__':
  main()

The problem is that the c_lib interrupt handling code doesn't treat the SIGALRM signal, this is fixed in the attached patch. It also changes some exception classes (instead of raising RuntimeError for every signal). Another cool new feature is that alarm() now works with a floating-point number of seconds.

Apply attachment: 13311_sigalrm.patch

Depends on #14029

CC: @pjbruin

Component: c_lib

Keywords: alarm signal interrupt

Author: Jeroen Demeyer

Reviewer: Peter Bruin

Merged: sage-5.13.beta3

Issue created by migration from https://trac.sagemath.org/ticket/13311

[JohnCremona]

comment:1

I don't know anything about alarm(). In this case mwrank is being used to compute the rank and it takes more then 3s.

[sagetrac-alexc]

comment:2

Replying to @JohnCremona:

I don't know anything about alarm(). In this case mwrank is being used to compute the rank and it takes more then 3s.

alarm(timelimit) is supposed to raise a KeyboardInterrupt exception after timelimit seconds. For some reason, despite mwrank running for more than 3 seconds, the computation isn't interrupted. Documentation for alarm can be found here: http://www.sagemath.org/doc/reference/sage/misc/misc.html#sage.misc.misc.alarm

[koffie]

comment:3

The following might help to locate the problem: http://www.sagemath.org/doc/developer/coding_in_cython.html#using-sig-on-and-sig-off

[jdemeyer]

comment:4

The problem is that the SIGALRM handling is completely independent of the usual signal handling, hence it doesn't work. It simply raises a Python-level KeyboardInterrupt, but that's it. It doesn't interact with any of the sophisticated sig_on()/sig_off() stuff.

As an ugly work-around, try using signal_after_delay() from sage.tests.interrupt, which generates an actual interrupt.

[jdemeyer]

Changed keywords from alarm elliptic curve curves ellipticcurve to alarm signal interrupt

[jdemeyer]

comment:5

This has absolutely nothing to do with elliptic curves...

[nexttime]

comment:6

Replying to @jdemeyer:

The problem is that the SIGALRM handling is completely independent of the usual signal handling, hence it doesn't work. [...]

As an ugly work-around, try using signal_after_delay() from sage.tests.interrupt, which generates an actual interrupt.

A "cleaner" work-around is to use the @fork decorator, such that the computation (implemented in Cython or e.g. C/C++) runs in a subprocess, while alarm() is used in the main (Python) process; cf. this solution on ask.sagemath.

[jdemeyer]

comment:7

Replying to @nexttime:

A "cleaner" work-around is to use the @fork decorator, such that the computation (implemented in Cython or e.g. C/C++) runs in a subprocess, while alarm() is used in the main (Python) process; cf. this solution on ask.sagemath.

I disagree with "cleaner" but that would work, yes.

[jdemeyer]

Dependencies: #14029

[jdemeyer]

Author: Jeroen Demeyer

[nexttime]

comment:10

Minor things:

"The latter signal also redirect stdin from /dev/null, to cause interactive sessions to exit also."

-> "The latter signal also redirects stdin from /dev/null, to cause interactive sessions to exit."

s/time out/time-out/ (or timeout, which is also used later on) a couple of times, and in the doctest error message s/Time out/Timed out/ (consistent with e.g. Interrupted).

In sig_raise_exception(), shouldn't the message in raise SystemError("unknown signal") contain the signal number?

[nexttime]

Replying to @jdemeyer:

Another cool new feature is that alarm() now works with a floating-point number of seconds.

Maybe on a real-time OS ... ;-)

[nexttime]

comment:13

P.S.: Patch looks ok, but I haven't had the time to test this (and #14029) yet.

[nexttime]

comment:14

Replying to @nexttime:

In sig_raise_exception(), shouldn't the message in raise SystemError("unknown signal") contain the signal number?

Ok, fixed now. Or more nit-picking:

Maybe

    raise SystemError("Received unknown signal number %s"%sig)

?

[pjbruin]

Work Issues: rebase

[pjbruin]

comment:17

This doesn't apply anymore to 5.12.rc1 + #14029; the patch fails on sage/ext/c_lib.pyx and sage/structure/parent.pyx.

[jdemeyer]

Attachment: 13311_sigalrm.patch.gz

[pjbruin]

comment:19

Generating a SIGALRM outside sig_on()...sig_off() calls PyErr_SetInterrupt(), which causes Python to raise a KeyboardInterrupt:

sage: alarm(1) 
sage: # wait 1 second
KeyboardInterrupt

The same thing already happens without this patch. Wouldn't it make sense to also raise an AlarmInterrupt outside sig_on()...sig_off(), too?

[jdemeyer]

comment:20

Replying to @pjbruin:

Generating a SIGALRM outside sig_on()...sig_off() calls PyErr_SetInterrupt(), which causes Python to raise a KeyboardInterrupt

No, it doesn't. It causes IPython to print the string "KeyboardInterrupt". See the difference with

sage: alarm(0.5); sleep(1)
---------------------------------------------------------------------------
AlarmInterrupt                            Traceback (most recent call last)
<ipython-input-3-854e6c430970> in <module>()
----> 1 alarm(RealNumber('0.5')); sleep(Integer(1))

/scratch/release/merger/sage-5.13.beta1/local/lib/python2.7/site-packages/sage/ext/c_lib.so in sage.ext.c_lib.sage_python_check_interrupt (sage/ext/c_lib.c:1634)()

/scratch/release/merger/sage-5.13.beta1/local/lib/python2.7/site-packages/sage/ext/c_lib.so in sage.ext.c_lib.sig_raise_exception (sage/ext/c_lib.c:894)()

AlarmInterrupt: 

[pjbruin]

comment:21

Replying to @jdemeyer:

Replying to @pjbruin:

Generating a SIGALRM outside sig_on()...sig_off() calls PyErr_SetInterrupt(), which causes Python to raise a KeyboardInterrupt

No, it doesn't. It causes IPython to print the string "KeyboardInterrupt".

I was mislead by the Python documentation, which says that PyErr_SetInterrupt() causes a KeyboardInterrupt to be raised the next time PyErr_CheckSignals() is called. In fact this only describes what Python's default SIGINT handler does, which we don't use.

OK, so IPython prints the string "KeyboardInterrupt" in an except KeyboardInterrupt block when it is reading input. Do I understand correctly that the KeyboardInterrupt is in this case actually an AlarmInterrupt and triggers this except block because it inherits from KeyboardInterrupt?

[jdemeyer]

comment:22

Replying to @pjbruin:

I was mislead by the Python documentation, which says that PyErr_SetInterrupt() causes a KeyboardInterrupt to be raised the next time PyErr_CheckSignals() is called. In fact this only describes what Python's default SIGINT handler does, which we don't use.

Indeed. The Python SIGINT handler is changed in _init_csage() from devel/sage/sage/ext/c_lib.pyx.

OK, so IPython prints the string "KeyboardInterrupt" in an except KeyboardInterrupt block when it is reading input. Do I understand correctly that the KeyboardInterrupt is in this case actually an AlarmInterrupt and triggers this except block because it inherits from KeyboardInterrupt?

Exactly.

[pjbruin]

comment:23

Replying to @jdemeyer:

No, it doesn't. It causes IPython to print the string "KeyboardInterrupt".

Given that an interrupt is not necessarily generated from the keyboard, it would be more logical from the user's perspective if IPython would print either (1) a generic message like "Interrupt", (2) a different string for KeyboardInterrupt and AlarmInterrupt, or even (3) nothing (Bash just prints a newline when you press ^C and nothing when you press ^\.)

I would be in favour of (2); to implement this, IPython could print E.__class__.__name__ inside except KeyboardInterrupt as E instead of the constant string "KeyboardInterrupt".

In principle it would also make more sense if KeyboardInterrupt and AlarmInterrupt would derive from a common Interrupt exception, but this is impossible since KeyboardInterrupt is a built-in Python exception.

[jdemeyer]

comment:24

Perhaps, but I don't believe it's worth the trouble to patch IPython for this.

[pjbruin]

comment:25

Replying to @jdemeyer:

Perhaps, but I don't believe it's worth the trouble to patch IPython for this.

Maybe, maybe not; in any case we can always do it later.

That issue aside, the patch looks good, behaves as expected and passes doctests.

[pjbruin]

Reviewer: Peter Bruin

[jdemeyer]

Changed work issues from rebase to none

[jdemeyer]

Merged: sage-5.13.beta3

[jdemeyer]

comment:28

I finally sent a patch to IPython about this: ipython/ipython#7069