1998-08-10 16:42:37 -03:00
|
|
|
\section{\module{signal} ---
|
2000-10-10 14:03:45 -03:00
|
|
|
Set handlers for asynchronous events}
|
1998-07-23 14:59:49 -03:00
|
|
|
|
2000-10-10 14:03:45 -03:00
|
|
|
\declaremodule{builtin}{signal}
|
1998-07-23 14:59:49 -03:00
|
|
|
\modulesynopsis{Set handlers for asynchronous events.}
|
1995-02-07 10:37:02 -04:00
|
|
|
|
2000-10-10 14:03:45 -03:00
|
|
|
|
1995-02-15 11:52:32 -04:00
|
|
|
This module provides mechanisms to use signal handlers in Python.
|
1998-08-18 16:38:54 -03:00
|
|
|
Some general rules for working with signals and their handlers:
|
1995-02-15 11:52:32 -04:00
|
|
|
|
|
|
|
\begin{itemize}
|
|
|
|
|
|
|
|
\item
|
|
|
|
A handler for a particular signal, once set, remains installed until
|
2001-07-06 17:30:11 -03:00
|
|
|
it is explicitly reset (Python emulates the BSD style interface
|
1996-02-12 19:18:51 -04:00
|
|
|
regardless of the underlying implementation), with the exception of
|
1998-01-22 11:56:41 -04:00
|
|
|
the handler for \constant{SIGCHLD}, which follows the underlying
|
1996-02-12 19:18:51 -04:00
|
|
|
implementation.
|
1995-02-15 11:52:32 -04:00
|
|
|
|
2003-03-13 09:56:53 -04:00
|
|
|
\item
|
|
|
|
There is no way to ``block'' signals temporarily from critical
|
|
|
|
sections (since this is not supported by all \UNIX{} flavors).
|
|
|
|
|
1995-02-15 11:52:32 -04:00
|
|
|
\item
|
|
|
|
Although Python signal handlers are called asynchronously as far as
|
|
|
|
the Python user is concerned, they can only occur between the
|
|
|
|
``atomic'' instructions of the Python interpreter. This means that
|
2001-07-06 17:30:11 -03:00
|
|
|
signals arriving during long calculations implemented purely in C
|
|
|
|
(such as regular expression matches on large bodies of text) may be
|
1995-03-17 12:07:09 -04:00
|
|
|
delayed for an arbitrary amount of time.
|
1995-02-15 11:52:32 -04:00
|
|
|
|
|
|
|
\item
|
|
|
|
When a signal arrives during an I/O operation, it is possible that the
|
|
|
|
I/O operation raises an exception after the signal handler returns.
|
1995-03-13 06:03:32 -04:00
|
|
|
This is dependent on the underlying \UNIX{} system's semantics regarding
|
1995-02-15 11:52:32 -04:00
|
|
|
interrupted system calls.
|
|
|
|
|
|
|
|
\item
|
1998-01-22 11:56:41 -04:00
|
|
|
Because the \C{} signal handler always returns, it makes little sense to
|
|
|
|
catch synchronous errors like \constant{SIGFPE} or \constant{SIGSEGV}.
|
1995-02-15 11:52:32 -04:00
|
|
|
|
|
|
|
\item
|
|
|
|
Python installs a small number of signal handlers by default:
|
1998-01-22 11:56:41 -04:00
|
|
|
\constant{SIGPIPE} is ignored (so write errors on pipes and sockets can be
|
1999-03-25 16:30:00 -04:00
|
|
|
reported as ordinary Python exceptions) and \constant{SIGINT} is translated
|
|
|
|
into a \exception{KeyboardInterrupt} exception. All of these can be
|
1995-02-15 11:52:32 -04:00
|
|
|
overridden.
|
|
|
|
|
|
|
|
\item
|
|
|
|
Some care must be taken if both signals and threads are used in the
|
|
|
|
same program. The fundamental thing to remember in using signals and
|
1998-01-22 11:56:41 -04:00
|
|
|
threads simultaneously is:\ always perform \function{signal()} operations
|
1995-03-13 06:03:32 -04:00
|
|
|
in the main thread of execution. Any thread can perform an
|
1998-01-22 11:56:41 -04:00
|
|
|
\function{alarm()}, \function{getsignal()}, or \function{pause()};
|
|
|
|
only the main thread can set a new signal handler, and the main thread
|
|
|
|
will be the only one to receive signals (this is enforced by the
|
|
|
|
Python \module{signal} module, even if the underlying thread
|
|
|
|
implementation supports sending signals to individual threads). This
|
2000-07-16 16:01:10 -03:00
|
|
|
means that signals can't be used as a means of inter-thread
|
1998-01-22 11:56:41 -04:00
|
|
|
communication. Use locks instead.
|
1995-02-15 11:52:32 -04:00
|
|
|
|
|
|
|
\end{itemize}
|
1995-02-07 10:37:02 -04:00
|
|
|
|
1998-01-22 11:56:41 -04:00
|
|
|
The variables defined in the \module{signal} module are:
|
1995-02-07 10:37:02 -04:00
|
|
|
|
|
|
|
\begin{datadesc}{SIG_DFL}
|
|
|
|
This is one of two standard signal handling options; it will simply
|
|
|
|
perform the default function for the signal. For example, on most
|
1998-01-22 11:56:41 -04:00
|
|
|
systems the default action for \constant{SIGQUIT} is to dump core
|
|
|
|
and exit, while the default action for \constant{SIGCLD} is to
|
|
|
|
simply ignore it.
|
1995-02-07 10:37:02 -04:00
|
|
|
\end{datadesc}
|
|
|
|
|
|
|
|
\begin{datadesc}{SIG_IGN}
|
|
|
|
This is another standard signal handler, which will simply ignore
|
|
|
|
the given signal.
|
|
|
|
\end{datadesc}
|
|
|
|
|
|
|
|
\begin{datadesc}{SIG*}
|
|
|
|
All the signal numbers are defined symbolically. For example, the
|
1998-01-22 11:56:41 -04:00
|
|
|
hangup signal is defined as \constant{signal.SIGHUP}; the variable names
|
1995-02-07 10:37:02 -04:00
|
|
|
are identical to the names used in C programs, as found in
|
1998-08-14 14:05:17 -03:00
|
|
|
\code{<signal.h>}.
|
1998-01-22 11:56:41 -04:00
|
|
|
The \UNIX{} man page for `\cfunction{signal()}' lists the existing
|
|
|
|
signals (on some systems this is \manpage{signal}{2}, on others the
|
|
|
|
list is in \manpage{signal}{7}).
|
1995-02-07 10:37:02 -04:00
|
|
|
Note that not all systems define the same set of signal names; only
|
|
|
|
those names defined by the system are defined by this module.
|
|
|
|
\end{datadesc}
|
|
|
|
|
1995-02-15 11:52:32 -04:00
|
|
|
\begin{datadesc}{NSIG}
|
|
|
|
One more than the number of the highest signal number.
|
|
|
|
\end{datadesc}
|
|
|
|
|
1998-01-22 11:56:41 -04:00
|
|
|
The \module{signal} module defines the following functions:
|
1995-02-07 10:37:02 -04:00
|
|
|
|
|
|
|
\begin{funcdesc}{alarm}{time}
|
|
|
|
If \var{time} is non-zero, this function requests that a
|
1998-01-22 11:56:41 -04:00
|
|
|
\constant{SIGALRM} signal be sent to the process in \var{time} seconds.
|
2001-07-06 17:30:11 -03:00
|
|
|
Any previously scheduled alarm is canceled (only one alarm can
|
1995-02-07 10:37:02 -04:00
|
|
|
be scheduled at any time). The returned value is then the number of
|
|
|
|
seconds before any previously set alarm was to have been delivered.
|
2006-04-21 07:40:58 -03:00
|
|
|
If \var{time} is zero, no alarm is scheduled, and any scheduled
|
Merged revisions 56154-56264 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/branches/p3yk
................
r56155 | neal.norwitz | 2007-07-03 08:59:08 +0300 (Tue, 03 Jul 2007) | 1 line
Get this test working after converting map to return an iterator
................
r56202 | neal.norwitz | 2007-07-09 04:30:09 +0300 (Mon, 09 Jul 2007) | 37 lines
Merged revisions 56124-56201 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r56129 | georg.brandl | 2007-06-30 04:01:01 -0700 (Sat, 30 Jun 2007) | 2 lines
Document smtp.SMTPAuthenticationError.
........
r56137 | georg.brandl | 2007-07-01 01:11:35 -0700 (Sun, 01 Jul 2007) | 2 lines
Fix a few webbrowser.py problems.
........
r56143 | georg.brandl | 2007-07-02 04:54:28 -0700 (Mon, 02 Jul 2007) | 2 lines
Remove duplicate sentence from alarm() doc.
........
r56170 | mark.hammond | 2007-07-03 19:03:10 -0700 (Tue, 03 Jul 2007) | 3 lines
copy built files to the PCBuild directory, where tools like
distutils or external build processes can find them.
........
r56176 | kurt.kaiser | 2007-07-05 15:03:39 -0700 (Thu, 05 Jul 2007) | 10 lines
Many calls to tk.call involve an arglist containing a single tuple.
Calls using METH_OLDARGS unpack this tuple; calls using METH_VARARG
don't. Tcl's concatenation of args was affected; IDLE doesn't start.
Modify Tkapp_Call() to unpack single tuple arglists.
Bug 1733943
Ref http://mail.python.org/pipermail/python-checkins/2007-May/060454.html
........
r56177 | neal.norwitz | 2007-07-05 21:13:39 -0700 (Thu, 05 Jul 2007) | 1 line
Fix typo in comment
........
................
r56251 | neal.norwitz | 2007-07-11 10:01:01 +0300 (Wed, 11 Jul 2007) | 1 line
Get working with map returning an iterator (had to fix whitespace too)
................
r56255 | thomas.wouters | 2007-07-11 13:41:37 +0300 (Wed, 11 Jul 2007) | 6 lines
Clean up merge glitch or copy-paste error (the entire module was duplicated,
except the first half even had some more copy-paste errors, referring to
listcomps and genexps instead of setcomps)
................
r56256 | thomas.wouters | 2007-07-11 15:16:01 +0300 (Wed, 11 Jul 2007) | 14 lines
Dict comprehensions. Still needs doc changes (like many python-3000 features
;-). It generates bytecode similar to:
x = {}
for k, v in (generator here):
x[k] = v
except there is no tuple-packing and -unpacking involved. Trivial
measurement suggests it's significantly faster than dict(generator here) (in
the order of 2 to 3 times as fast) but I have not done extensive
measurements.
................
r56263 | guido.van.rossum | 2007-07-11 15:36:26 +0300 (Wed, 11 Jul 2007) | 3 lines
Patch 1724999 by Ali Gholami Rudi -- avoid complaints about dict size
change during iter in destroy call.
................
2007-07-11 10:09:30 -03:00
|
|
|
alarm is canceled. If the return value
|
2002-02-15 16:59:43 -04:00
|
|
|
is zero, no alarm is currently scheduled. (See the \UNIX{} man page
|
|
|
|
\manpage{alarm}{2}.)
|
|
|
|
Availability: \UNIX.
|
1995-02-07 10:37:02 -04:00
|
|
|
\end{funcdesc}
|
|
|
|
|
|
|
|
\begin{funcdesc}{getsignal}{signalnum}
|
1995-03-13 06:03:32 -04:00
|
|
|
Return the current signal handler for the signal \var{signalnum}.
|
1995-02-07 10:37:02 -04:00
|
|
|
The returned value may be a callable Python object, or one of the
|
1998-01-22 11:56:41 -04:00
|
|
|
special values \constant{signal.SIG_IGN}, \constant{signal.SIG_DFL} or
|
|
|
|
\constant{None}. Here, \constant{signal.SIG_IGN} means that the
|
|
|
|
signal was previously ignored, \constant{signal.SIG_DFL} means that the
|
|
|
|
default way of handling the signal was previously in use, and
|
|
|
|
\code{None} means that the previous signal handler was not installed
|
|
|
|
from Python.
|
1995-02-07 10:37:02 -04:00
|
|
|
\end{funcdesc}
|
|
|
|
|
|
|
|
\begin{funcdesc}{pause}{}
|
1995-03-13 06:03:32 -04:00
|
|
|
Cause the process to sleep until a signal is received; the
|
2002-02-15 16:36:19 -04:00
|
|
|
appropriate handler will then be called. Returns nothing. Not on
|
|
|
|
Windows. (See the \UNIX{} man page \manpage{signal}{2}.)
|
1995-02-07 10:37:02 -04:00
|
|
|
\end{funcdesc}
|
|
|
|
|
1998-03-17 02:33:25 -04:00
|
|
|
\begin{funcdesc}{signal}{signalnum, handler}
|
1995-03-13 06:03:32 -04:00
|
|
|
Set the handler for signal \var{signalnum} to the function
|
1998-06-09 12:42:25 -03:00
|
|
|
\var{handler}. \var{handler} can be a callable Python object
|
|
|
|
taking two arguments (see below), or
|
1998-01-22 11:56:41 -04:00
|
|
|
one of the special values \constant{signal.SIG_IGN} or
|
|
|
|
\constant{signal.SIG_DFL}. The previous signal handler will be returned
|
|
|
|
(see the description of \function{getsignal()} above). (See the
|
|
|
|
\UNIX{} man page \manpage{signal}{2}.)
|
1995-02-07 10:37:02 -04:00
|
|
|
|
1995-02-15 11:52:32 -04:00
|
|
|
When threads are enabled, this function can only be called from the
|
1995-02-07 10:37:02 -04:00
|
|
|
main thread; attempting to call it from other threads will cause a
|
1998-01-22 11:56:41 -04:00
|
|
|
\exception{ValueError} exception to be raised.
|
1995-03-17 12:07:09 -04:00
|
|
|
|
|
|
|
The \var{handler} is called with two arguments: the signal number
|
2004-09-04 18:14:34 -03:00
|
|
|
and the current stack frame (\code{None} or a frame object;
|
|
|
|
for a description of frame objects, see the reference manual section
|
|
|
|
on the standard type hierarchy or see the attribute descriptions in
|
|
|
|
the \refmodule{inspect} module).
|
1995-02-07 10:37:02 -04:00
|
|
|
\end{funcdesc}
|
1998-08-18 16:38:54 -03:00
|
|
|
|
|
|
|
\subsection{Example}
|
|
|
|
\nodename{Signal Example}
|
|
|
|
|
|
|
|
Here is a minimal example program. It uses the \function{alarm()}
|
|
|
|
function to limit the time spent waiting to open a file; this is
|
|
|
|
useful if the file is for a serial device that may not be turned on,
|
|
|
|
which would normally cause the \function{os.open()} to hang
|
|
|
|
indefinitely. The solution is to set a 5-second alarm before opening
|
|
|
|
the file; if the operation takes too long, the alarm signal will be
|
|
|
|
sent, and the handler raises an exception.
|
|
|
|
|
|
|
|
\begin{verbatim}
|
2001-05-10 12:57:17 -03:00
|
|
|
import signal, os
|
1998-08-18 16:38:54 -03:00
|
|
|
|
|
|
|
def handler(signum, frame):
|
|
|
|
print 'Signal handler called with signal', signum
|
|
|
|
raise IOError, "Couldn't open device!"
|
|
|
|
|
|
|
|
# Set the signal handler and a 5-second alarm
|
|
|
|
signal.signal(signal.SIGALRM, handler)
|
|
|
|
signal.alarm(5)
|
|
|
|
|
|
|
|
# This open() may hang indefinitely
|
2001-05-10 12:57:17 -03:00
|
|
|
fd = os.open('/dev/ttyS0', os.O_RDWR)
|
1998-08-18 16:38:54 -03:00
|
|
|
|
|
|
|
signal.alarm(0) # Disable the alarm
|
|
|
|
\end{verbatim}
|