-
-
Notifications
You must be signed in to change notification settings - Fork 556
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
alarm() doesn't work for Cython code #13311
Comments
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. |
comment:2
Replying to @JohnCremona:
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 |
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 |
comment:4
The problem is that the As an ugly work-around, try using |
Changed keywords from alarm elliptic curve curves ellipticcurve to alarm signal interrupt |
comment:5
This has absolutely nothing to do with elliptic curves... |
comment:6
Replying to @jdemeyer:
A "cleaner" work-around is to use the |
comment:7
Replying to @nexttime:
I disagree with "cleaner" but that would work, yes. |
Dependencies: #14029 |
Author: Jeroen Demeyer |
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."
In |
This comment has been minimized.
This comment has been minimized.
Replying to @jdemeyer:
Maybe on a real-time OS ... ;-) |
comment:13
P.S.: Patch looks ok, but I haven't had the time to test this (and #14029) yet. |
comment:14
Replying to @nexttime:
Ok, fixed now. Or more nit-picking: Maybe raise SystemError("Received unknown signal number %s"%sig) ? |
Work Issues: rebase |
comment:17
This doesn't apply anymore to 5.12.rc1 + #14029; the patch fails on |
Attachment: 13311_sigalrm.patch.gz |
comment:19
Generating a
The same thing already happens without this patch. Wouldn't it make sense to also raise an |
comment:20
Replying to @pjbruin:
No, it doesn't. It causes IPython to print the string
|
comment:21
Replying to @jdemeyer:
I was mislead by the Python documentation, which says that OK, so IPython prints the string |
comment:22
Replying to @pjbruin:
Indeed. The Python
Exactly. |
comment:23
Replying to @jdemeyer:
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 I would be in favour of (2); to implement this, IPython could print In principle it would also make more sense if |
comment:24
Perhaps, but I don't believe it's worth the trouble to patch IPython for this. |
comment:25
Replying to @jdemeyer:
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. |
Reviewer: Peter Bruin |
Changed work issues from rebase to none |
Merged: sage-5.13.beta3 |
comment:28
I finally sent a patch to IPython about this: ipython/ipython#7069 |
The following code does not work as intended (I imagine), i.e. it does not interrupt the computation after 3 seconds.
The problem is that the
c_lib
interrupt handling code doesn't treat theSIGALRM
signal, this is fixed in the attached patch. It also changes some exception classes (instead of raisingRuntimeError
for every signal). Another cool new feature is thatalarm()
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
The text was updated successfully, but these errors were encountered: