1 | \section{\module{signal} ---
|
---|
2 | Set handlers for asynchronous events}
|
---|
3 |
|
---|
4 | \declaremodule{builtin}{signal}
|
---|
5 | \modulesynopsis{Set handlers for asynchronous events.}
|
---|
6 |
|
---|
7 |
|
---|
8 | This module provides mechanisms to use signal handlers in Python.
|
---|
9 | Some general rules for working with signals and their handlers:
|
---|
10 |
|
---|
11 | \begin{itemize}
|
---|
12 |
|
---|
13 | \item
|
---|
14 | A handler for a particular signal, once set, remains installed until
|
---|
15 | it is explicitly reset (Python emulates the BSD style interface
|
---|
16 | regardless of the underlying implementation), with the exception of
|
---|
17 | the handler for \constant{SIGCHLD}, which follows the underlying
|
---|
18 | implementation.
|
---|
19 |
|
---|
20 | \item
|
---|
21 | There is no way to ``block'' signals temporarily from critical
|
---|
22 | sections (since this is not supported by all \UNIX{} flavors).
|
---|
23 |
|
---|
24 | \item
|
---|
25 | Although Python signal handlers are called asynchronously as far as
|
---|
26 | the Python user is concerned, they can only occur between the
|
---|
27 | ``atomic'' instructions of the Python interpreter. This means that
|
---|
28 | signals arriving during long calculations implemented purely in C
|
---|
29 | (such as regular expression matches on large bodies of text) may be
|
---|
30 | delayed for an arbitrary amount of time.
|
---|
31 |
|
---|
32 | \item
|
---|
33 | When a signal arrives during an I/O operation, it is possible that the
|
---|
34 | I/O operation raises an exception after the signal handler returns.
|
---|
35 | This is dependent on the underlying \UNIX{} system's semantics regarding
|
---|
36 | interrupted system calls.
|
---|
37 |
|
---|
38 | \item
|
---|
39 | Because the \C{} signal handler always returns, it makes little sense to
|
---|
40 | catch synchronous errors like \constant{SIGFPE} or \constant{SIGSEGV}.
|
---|
41 |
|
---|
42 | \item
|
---|
43 | Python installs a small number of signal handlers by default:
|
---|
44 | \constant{SIGPIPE} is ignored (so write errors on pipes and sockets can be
|
---|
45 | reported as ordinary Python exceptions) and \constant{SIGINT} is translated
|
---|
46 | into a \exception{KeyboardInterrupt} exception. All of these can be
|
---|
47 | overridden.
|
---|
48 |
|
---|
49 | \item
|
---|
50 | Some care must be taken if both signals and threads are used in the
|
---|
51 | same program. The fundamental thing to remember in using signals and
|
---|
52 | threads simultaneously is:\ always perform \function{signal()} operations
|
---|
53 | in the main thread of execution. Any thread can perform an
|
---|
54 | \function{alarm()}, \function{getsignal()}, or \function{pause()};
|
---|
55 | only the main thread can set a new signal handler, and the main thread
|
---|
56 | will be the only one to receive signals (this is enforced by the
|
---|
57 | Python \module{signal} module, even if the underlying thread
|
---|
58 | implementation supports sending signals to individual threads). This
|
---|
59 | means that signals can't be used as a means of inter-thread
|
---|
60 | communication. Use locks instead.
|
---|
61 |
|
---|
62 | \end{itemize}
|
---|
63 |
|
---|
64 | The variables defined in the \module{signal} module are:
|
---|
65 |
|
---|
66 | \begin{datadesc}{SIG_DFL}
|
---|
67 | This is one of two standard signal handling options; it will simply
|
---|
68 | perform the default function for the signal. For example, on most
|
---|
69 | systems the default action for \constant{SIGQUIT} is to dump core
|
---|
70 | and exit, while the default action for \constant{SIGCLD} is to
|
---|
71 | simply ignore it.
|
---|
72 | \end{datadesc}
|
---|
73 |
|
---|
74 | \begin{datadesc}{SIG_IGN}
|
---|
75 | This is another standard signal handler, which will simply ignore
|
---|
76 | the given signal.
|
---|
77 | \end{datadesc}
|
---|
78 |
|
---|
79 | \begin{datadesc}{SIG*}
|
---|
80 | All the signal numbers are defined symbolically. For example, the
|
---|
81 | hangup signal is defined as \constant{signal.SIGHUP}; the variable names
|
---|
82 | are identical to the names used in C programs, as found in
|
---|
83 | \code{<signal.h>}.
|
---|
84 | The \UNIX{} man page for `\cfunction{signal()}' lists the existing
|
---|
85 | signals (on some systems this is \manpage{signal}{2}, on others the
|
---|
86 | list is in \manpage{signal}{7}).
|
---|
87 | Note that not all systems define the same set of signal names; only
|
---|
88 | those names defined by the system are defined by this module.
|
---|
89 | \end{datadesc}
|
---|
90 |
|
---|
91 | \begin{datadesc}{NSIG}
|
---|
92 | One more than the number of the highest signal number.
|
---|
93 | \end{datadesc}
|
---|
94 |
|
---|
95 | The \module{signal} module defines the following functions:
|
---|
96 |
|
---|
97 | \begin{funcdesc}{alarm}{time}
|
---|
98 | If \var{time} is non-zero, this function requests that a
|
---|
99 | \constant{SIGALRM} signal be sent to the process in \var{time} seconds.
|
---|
100 | Any previously scheduled alarm is canceled (only one alarm can
|
---|
101 | be scheduled at any time). The returned value is then the number of
|
---|
102 | seconds before any previously set alarm was to have been delivered.
|
---|
103 | If \var{time} is zero, no alarm is scheduled, and any scheduled
|
---|
104 | alarm is canceled. The return value is the number of seconds
|
---|
105 | remaining before a previously scheduled alarm. If the return value
|
---|
106 | is zero, no alarm is currently scheduled. (See the \UNIX{} man page
|
---|
107 | \manpage{alarm}{2}.)
|
---|
108 | Availability: \UNIX.
|
---|
109 | \end{funcdesc}
|
---|
110 |
|
---|
111 | \begin{funcdesc}{getsignal}{signalnum}
|
---|
112 | Return the current signal handler for the signal \var{signalnum}.
|
---|
113 | The returned value may be a callable Python object, or one of the
|
---|
114 | special values \constant{signal.SIG_IGN}, \constant{signal.SIG_DFL} or
|
---|
115 | \constant{None}. Here, \constant{signal.SIG_IGN} means that the
|
---|
116 | signal was previously ignored, \constant{signal.SIG_DFL} means that the
|
---|
117 | default way of handling the signal was previously in use, and
|
---|
118 | \code{None} means that the previous signal handler was not installed
|
---|
119 | from Python.
|
---|
120 | \end{funcdesc}
|
---|
121 |
|
---|
122 | \begin{funcdesc}{pause}{}
|
---|
123 | Cause the process to sleep until a signal is received; the
|
---|
124 | appropriate handler will then be called. Returns nothing. Not on
|
---|
125 | Windows. (See the \UNIX{} man page \manpage{signal}{2}.)
|
---|
126 | \end{funcdesc}
|
---|
127 |
|
---|
128 | \begin{funcdesc}{signal}{signalnum, handler}
|
---|
129 | Set the handler for signal \var{signalnum} to the function
|
---|
130 | \var{handler}. \var{handler} can be a callable Python object
|
---|
131 | taking two arguments (see below), or
|
---|
132 | one of the special values \constant{signal.SIG_IGN} or
|
---|
133 | \constant{signal.SIG_DFL}. The previous signal handler will be returned
|
---|
134 | (see the description of \function{getsignal()} above). (See the
|
---|
135 | \UNIX{} man page \manpage{signal}{2}.)
|
---|
136 |
|
---|
137 | When threads are enabled, this function can only be called from the
|
---|
138 | main thread; attempting to call it from other threads will cause a
|
---|
139 | \exception{ValueError} exception to be raised.
|
---|
140 |
|
---|
141 | The \var{handler} is called with two arguments: the signal number
|
---|
142 | and the current stack frame (\code{None} or a frame object;
|
---|
143 | for a description of frame objects, see the reference manual section
|
---|
144 | on the standard type hierarchy or see the attribute descriptions in
|
---|
145 | the \refmodule{inspect} module).
|
---|
146 | \end{funcdesc}
|
---|
147 |
|
---|
148 | \subsection{Example}
|
---|
149 | \nodename{Signal Example}
|
---|
150 |
|
---|
151 | Here is a minimal example program. It uses the \function{alarm()}
|
---|
152 | function to limit the time spent waiting to open a file; this is
|
---|
153 | useful if the file is for a serial device that may not be turned on,
|
---|
154 | which would normally cause the \function{os.open()} to hang
|
---|
155 | indefinitely. The solution is to set a 5-second alarm before opening
|
---|
156 | the file; if the operation takes too long, the alarm signal will be
|
---|
157 | sent, and the handler raises an exception.
|
---|
158 |
|
---|
159 | \begin{verbatim}
|
---|
160 | import signal, os
|
---|
161 |
|
---|
162 | def handler(signum, frame):
|
---|
163 | print 'Signal handler called with signal', signum
|
---|
164 | raise IOError, "Couldn't open device!"
|
---|
165 |
|
---|
166 | # Set the signal handler and a 5-second alarm
|
---|
167 | signal.signal(signal.SIGALRM, handler)
|
---|
168 | signal.alarm(5)
|
---|
169 |
|
---|
170 | # This open() may hang indefinitely
|
---|
171 | fd = os.open('/dev/ttyS0', os.O_RDWR)
|
---|
172 |
|
---|
173 | signal.alarm(0) # Disable the alarm
|
---|
174 | \end{verbatim}
|
---|