On Thu, Feb 7, 2019 at 4:13 PM E. Madison Bray <erik.m.b...@gmail.com> wrote: > > On Wed, Feb 6, 2019 at 8:52 PM Nils Bruin <nbr...@sfu.ca> wrote: > > > > On Wednesday, February 6, 2019 at 6:35:27 AM UTC-8, E. Madison Bray wrote: > >> > >> > >> Which is being reached because AlarmInterrupt is a subclass of > >> KeyboardInterrupt . I don't know why this doesn't happen then when, > >> say, mashing Ctrl-C. I guess because IPython installs its own SIGINT > >> handler or something. > > > > > > In IPython proper the behaviour is different: > > > > > > In [1]: import signal > > > > In [2]: signal.alarm(1) > > Out[2]: 0 > > > > In [3]: Alarm clock > > <exit> > > > > This is the same as in python: > > > > >>> import signal > > >>> signal.alarm(1) > > 0 > > >>> Alarm clock > > > > It looks like this is just the default signal handler for python (the one > > that just prints the signal name and exits) > > > > Note that cysignals.signals.AlarmInterrupt is our own invention, so if the > > problem is inheriting from KeyboardInterrupt, we should probably not do > > that. > > IIRC there is a good rationale for that, though I don't see it > explicitly documented anywhere. I think it's simply that in most code > where you would want to catch an AlarmInterrupt (i.e. you set an alarm > on some code that should not be allowed to run for more than a certain > amount of time), you would also likely want to break out of it > manually with a Ctrl-C, and you would want those two cases handled the > same. So you kill two birds with one stone this way, rather than > having to write `except (AlarmInterrupt, KeyboardInterrupt)`. In > other words, the AlarmInterrupt is treated sort of as an automatic > KeyboardInterrupt on a timer. > > This can be avoided of course by explicitly writing `except > (AlarmInterrupt, KeyboardInterrupt)`, but I do like the existing > design on principle. I think in this case its better to address the > specific problem. I find it odd that IPython would allow an interrupt > arising from user code to break out of its event loop. It seems to > happen in the case of code being run via signal handlers, because if I > just enter `raise KeyboardInterrupt` at the prompt, this happens: > > sage: raise KeyboardInterrupt > --------------------------------------------------------------------------- > KeyboardInterrupt Traceback (most recent call last) > <ipython-input-1-c761920b81b0> in <module>() > ----> 1 raise KeyboardInterrupt > > KeyboardInterrupt: > > So, no problem. But I can reproduce the problem with Sage's alarm() > using pure Python+stdlib like: > > sage: import signal > sage: def raise_keyboard_interrupt(*args): > ....: raise KeyboardInterrupt > ....: > sage: signal.signal(signal.SIGALRM, raise_keyboard_interrupt) > 0 > sage: signal.alarm(1) > 0
Forgot to paste the rest of this example. Point being it does the same thing: sage: import signal sage: def raise_keyboard_interrupt(*args): ....: raise KeyboardInterrupt ....: sage: signal.signal(signal.SIGALRM, raise_keyboard_interrupt) 0 sage: signal.alarm(1) 0 sage: KeyboardInterrupt escaped interact() sage: sage: ^[[41;1R ********************************************************************** Oops, Sage crashed. We do our best to make it stable, but... -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
