On Sat, May 11, 2013 at 8:05 PM, leif <not.rea...@online.de> wrote:
> William Stein wrote:
>>
>> On Sat, May 11, 2013 at 6:19 PM, Nils Bruin <nbr...@sfu.ca> wrote:
>>>
>>> On May 11, 2:15 pm, Thierry <sage-googlesu...@lma.metelu.net> wrote:
>>>>
>>>> Hi,
>>>>
>>>> it was reported
>>>> inhttp://ask.sagemath.org/question/2567/kill-the-thread-in-a-long-compu...
>>>> that cython seems not to handle Python signals correctly. It-it a
>>>> feature or should-it be reported ?
>>>
>>>
>>> I think it's a feature. There's a lot of code that reacts badly to
>>> being interrupted by signals. If I'm not mistaken, most of our code
>>> runs with signals disabled. It's the responsibility of the library
>>> function authors to insert sig_on and sig_off things to allow
>>> occasional signals to be processed when doing so is safe. Apparently
>>> that didn't happen for `factor`!
>>
>>
>> No, it did happen with factor (in fact, that might be one of the first
>> functions that motivated me to write the first sig_on/sig_off). If
>> you look at the ask.sagemath discussion, you'll see everything got
>> sorted out, and mainly there was a mistake in the original poster's
>> code. They had written something silly and got confused about the
>> order of evaluation.
>
>
> Nope, they had to resort to using @fork.
>
> Try e.g.:
>
> sage: alarm(10); factor(next_prime(2^300)*next_prime(2^400))
>
> (This uses sage.misc.misc.alarm(), which installs a handler raising a
> KeyboardInterrupt, after the specified number of seconds, but that does no
> longer work as expected, at least not in conjunction with factoring using
> the PARI library. You can of course still *manually* interrupt the
> computation, and *after* doing so, the SIGALRM gets delivered, or perhaps
> just the second KeyboardInterrupt /handled/, but I think the first thing
> happens, i.e., apparently sig_on() [or PARI] block SIGALRM.)
Many thanks for the clarification!
And indeed, if after typing "set_alarm" you send Sage (while
factoring) a SIGALRM signal by doing "kill -14 pid" from another
shell, it ignores it. Maybe sig_on/sig_off watches for SIGINT, not
for SIGALRM. I know that when I wrote the first version of
sig_on/sig_off, I choose a few specific signals (I think SIGINT and
floating point/math exceptions, etc.) to watch for and nothing else.
And don't know what Jereon did when he rewrote it.
If you don't do set_alarm first (so the Python signal handler isn't
changed to the one that raises a KeyboardInterrupt), then when running
the factor code, Sage will terminate (rather than ignoring it). I.e.,
SIGALARM is not ignored.
By the way, the alarm function in Sage uses Python's "signal.alarm",
whose source code is this:
static PyObject *
signal_alarm(PyObject *self, PyObject *args)
{
int t;
if (!PyArg_ParseTuple(args, "i:alarm", &t))
return NULL;
/* alarm() returns the number of seconds remaining */
return PyInt_FromLong((long)alarm(t));
}
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
