[ python-Bugs-1326841 ] SIGALRM alarm signal kills interpreter

[SourceForge.net]

Bugs item #1326841, was opened at 2005-10-14 14:48
Message generated for change (Comment added) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326841&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Demos and Tools
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: SIGALRM alarm signal kills interpreter

Initial Comment:
This may be similar to #210641.  Example (Python 2.4.1,
Fedora Core 4 GNU/Linux):

sh-3.00$ python
Python 2.4.1 (#1, May 16 2005, 15:19:29)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import signal
>>> signal.alarm(1)      # 1 second passes...
0
>>> Alarm clock
sh-3.00$   # python has exited

Doing the same thing in IDLE results in the subprocess
restarting.

IMO the correct behavior would be to raise an exception
that the outer shell would catch.


----------------------------------------------------------------------

>Comment By: paul rubin (phr)
Date: 2005-10-17 07:56

Message:
Logged In: YES 
user_id=72053

How would you feel about an RFE proposing to add a default
SIGALRM handler that raises some new exception like
'AlarmInterrupt', analogous to KeyboardInterrupt that gets
raised if the user hits ^C.  I think that's more in the
Python spirit of maintaining a controlled environment where
at worst, if there's an unhandled exception, the interpreter
prints a stack trace and shuts down cleanly instead of just
blipping out of existence with i/o pending and whatnot. 
There might be some other signals that should also be caught
like that.  In fact KeyboardInterrupt, AlarmInterrupt, etc.
could all be subclasses of an Interrupt class of exceptions.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2005-10-15 15:53

Message:
Logged In: YES 
user_id=21627

This is not a bug. It is documented that way: the default
handler is SIG_DFL, which in turn does the system default
for the signal. For Sigalarm, it is to terminate the process.

If you want an exception raised, you need to install a
signal handler:

>>> def doalarm(signum,frame):
...   raise "alarm"
...
>>> signal.signal(signal.SIGALRM, doalarm)
<function doalalarm at 0xb7d897d4>
>>> signal.alarm(3)
0
>>>
Traceback (most recent call last):
  File "<stdin>", line 0, in ?
  File "<stdin>", line 2, in doalarm
alarm


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326841&group_id=5470