[2] | 1 |
|
---|
| 2 | :mod:`signal` --- Set handlers for asynchronous events
|
---|
| 3 | ======================================================
|
---|
| 4 |
|
---|
| 5 | .. module:: signal
|
---|
| 6 | :synopsis: Set handlers for asynchronous events.
|
---|
| 7 |
|
---|
| 8 |
|
---|
| 9 | This module provides mechanisms to use signal handlers in Python. Some general
|
---|
| 10 | rules for working with signals and their handlers:
|
---|
| 11 |
|
---|
| 12 | * A handler for a particular signal, once set, remains installed until it is
|
---|
| 13 | explicitly reset (Python emulates the BSD style interface regardless of the
|
---|
| 14 | underlying implementation), with the exception of the handler for
|
---|
| 15 | :const:`SIGCHLD`, which follows the underlying implementation.
|
---|
| 16 |
|
---|
| 17 | * There is no way to "block" signals temporarily from critical sections (since
|
---|
| 18 | this is not supported by all Unix flavors).
|
---|
| 19 |
|
---|
| 20 | * Although Python signal handlers are called asynchronously as far as the Python
|
---|
| 21 | user is concerned, they can only occur between the "atomic" instructions of the
|
---|
| 22 | Python interpreter. This means that signals arriving during long calculations
|
---|
| 23 | implemented purely in C (such as regular expression matches on large bodies of
|
---|
| 24 | text) may be delayed for an arbitrary amount of time.
|
---|
| 25 |
|
---|
| 26 | * When a signal arrives during an I/O operation, it is possible that the I/O
|
---|
| 27 | operation raises an exception after the signal handler returns. This is
|
---|
| 28 | dependent on the underlying Unix system's semantics regarding interrupted system
|
---|
| 29 | calls.
|
---|
| 30 |
|
---|
| 31 | * Because the C signal handler always returns, it makes little sense to catch
|
---|
| 32 | synchronous errors like :const:`SIGFPE` or :const:`SIGSEGV`.
|
---|
| 33 |
|
---|
| 34 | * Python installs a small number of signal handlers by default: :const:`SIGPIPE`
|
---|
| 35 | is ignored (so write errors on pipes and sockets can be reported as ordinary
|
---|
| 36 | Python exceptions) and :const:`SIGINT` is translated into a
|
---|
| 37 | :exc:`KeyboardInterrupt` exception. All of these can be overridden.
|
---|
| 38 |
|
---|
| 39 | * Some care must be taken if both signals and threads are used in the same
|
---|
| 40 | program. The fundamental thing to remember in using signals and threads
|
---|
| 41 | simultaneously is: always perform :func:`signal` operations in the main thread
|
---|
| 42 | of execution. Any thread can perform an :func:`alarm`, :func:`getsignal`,
|
---|
| 43 | :func:`pause`, :func:`setitimer` or :func:`getitimer`; only the main thread
|
---|
| 44 | can set a new signal handler, and the main thread will be the only one to
|
---|
| 45 | receive signals (this is enforced by the Python :mod:`signal` module, even
|
---|
| 46 | if the underlying thread implementation supports sending signals to
|
---|
| 47 | individual threads). This means that signals can't be used as a means of
|
---|
| 48 | inter-thread communication. Use locks instead.
|
---|
| 49 |
|
---|
| 50 | The variables defined in the :mod:`signal` module are:
|
---|
| 51 |
|
---|
| 52 |
|
---|
| 53 | .. data:: SIG_DFL
|
---|
| 54 |
|
---|
| 55 | This is one of two standard signal handling options; it will simply perform
|
---|
| 56 | the default function for the signal. For example, on most systems the
|
---|
| 57 | default action for :const:`SIGQUIT` is to dump core and exit, while the
|
---|
| 58 | default action for :const:`SIGCHLD` is to simply ignore it.
|
---|
| 59 |
|
---|
| 60 |
|
---|
| 61 | .. data:: SIG_IGN
|
---|
| 62 |
|
---|
| 63 | This is another standard signal handler, which will simply ignore the given
|
---|
| 64 | signal.
|
---|
| 65 |
|
---|
| 66 |
|
---|
| 67 | .. data:: SIG*
|
---|
| 68 |
|
---|
| 69 | All the signal numbers are defined symbolically. For example, the hangup signal
|
---|
| 70 | is defined as :const:`signal.SIGHUP`; the variable names are identical to the
|
---|
| 71 | names used in C programs, as found in ``<signal.h>``. The Unix man page for
|
---|
[391] | 72 | ':c:func:`signal`' lists the existing signals (on some systems this is
|
---|
[2] | 73 | :manpage:`signal(2)`, on others the list is in :manpage:`signal(7)`). Note that
|
---|
| 74 | not all systems define the same set of signal names; only those names defined by
|
---|
| 75 | the system are defined by this module.
|
---|
| 76 |
|
---|
| 77 |
|
---|
[391] | 78 | .. data:: CTRL_C_EVENT
|
---|
| 79 |
|
---|
| 80 | The signal corresponding to the CTRL+C keystroke event. This signal can
|
---|
| 81 | only be used with :func:`os.kill`.
|
---|
| 82 |
|
---|
| 83 | Availability: Windows.
|
---|
| 84 |
|
---|
| 85 | .. versionadded:: 2.7
|
---|
| 86 |
|
---|
| 87 |
|
---|
| 88 | .. data:: CTRL_BREAK_EVENT
|
---|
| 89 |
|
---|
| 90 | The signal corresponding to the CTRL+BREAK keystroke event. This signal can
|
---|
| 91 | only be used with :func:`os.kill`.
|
---|
| 92 |
|
---|
| 93 | Availability: Windows.
|
---|
| 94 |
|
---|
| 95 | .. versionadded:: 2.7
|
---|
| 96 |
|
---|
| 97 |
|
---|
[2] | 98 | .. data:: NSIG
|
---|
| 99 |
|
---|
| 100 | One more than the number of the highest signal number.
|
---|
| 101 |
|
---|
| 102 |
|
---|
| 103 | .. data:: ITIMER_REAL
|
---|
| 104 |
|
---|
| 105 | Decrements interval timer in real time, and delivers :const:`SIGALRM` upon expiration.
|
---|
| 106 |
|
---|
| 107 |
|
---|
| 108 | .. data:: ITIMER_VIRTUAL
|
---|
| 109 |
|
---|
| 110 | Decrements interval timer only when the process is executing, and delivers
|
---|
| 111 | SIGVTALRM upon expiration.
|
---|
| 112 |
|
---|
| 113 |
|
---|
| 114 | .. data:: ITIMER_PROF
|
---|
| 115 |
|
---|
| 116 | Decrements interval timer both when the process executes and when the
|
---|
| 117 | system is executing on behalf of the process. Coupled with ITIMER_VIRTUAL,
|
---|
| 118 | this timer is usually used to profile the time spent by the application
|
---|
| 119 | in user and kernel space. SIGPROF is delivered upon expiration.
|
---|
| 120 |
|
---|
| 121 |
|
---|
| 122 | The :mod:`signal` module defines one exception:
|
---|
| 123 |
|
---|
| 124 | .. exception:: ItimerError
|
---|
| 125 |
|
---|
| 126 | Raised to signal an error from the underlying :func:`setitimer` or
|
---|
| 127 | :func:`getitimer` implementation. Expect this error if an invalid
|
---|
| 128 | interval timer or a negative time is passed to :func:`setitimer`.
|
---|
| 129 | This error is a subtype of :exc:`IOError`.
|
---|
| 130 |
|
---|
| 131 |
|
---|
| 132 | The :mod:`signal` module defines the following functions:
|
---|
| 133 |
|
---|
| 134 |
|
---|
| 135 | .. function:: alarm(time)
|
---|
| 136 |
|
---|
| 137 | If *time* is non-zero, this function requests that a :const:`SIGALRM` signal be
|
---|
| 138 | sent to the process in *time* seconds. Any previously scheduled alarm is
|
---|
| 139 | canceled (only one alarm can be scheduled at any time). The returned value is
|
---|
| 140 | then the number of seconds before any previously set alarm was to have been
|
---|
| 141 | delivered. If *time* is zero, no alarm is scheduled, and any scheduled alarm is
|
---|
| 142 | canceled. If the return value is zero, no alarm is currently scheduled. (See
|
---|
| 143 | the Unix man page :manpage:`alarm(2)`.) Availability: Unix.
|
---|
| 144 |
|
---|
| 145 |
|
---|
| 146 | .. function:: getsignal(signalnum)
|
---|
| 147 |
|
---|
| 148 | Return the current signal handler for the signal *signalnum*. The returned value
|
---|
| 149 | may be a callable Python object, or one of the special values
|
---|
| 150 | :const:`signal.SIG_IGN`, :const:`signal.SIG_DFL` or :const:`None`. Here,
|
---|
| 151 | :const:`signal.SIG_IGN` means that the signal was previously ignored,
|
---|
| 152 | :const:`signal.SIG_DFL` means that the default way of handling the signal was
|
---|
| 153 | previously in use, and ``None`` means that the previous signal handler was not
|
---|
| 154 | installed from Python.
|
---|
| 155 |
|
---|
| 156 |
|
---|
| 157 | .. function:: pause()
|
---|
| 158 |
|
---|
| 159 | Cause the process to sleep until a signal is received; the appropriate handler
|
---|
| 160 | will then be called. Returns nothing. Not on Windows. (See the Unix man page
|
---|
| 161 | :manpage:`signal(2)`.)
|
---|
| 162 |
|
---|
| 163 |
|
---|
| 164 | .. function:: setitimer(which, seconds[, interval])
|
---|
| 165 |
|
---|
| 166 | Sets given interval timer (one of :const:`signal.ITIMER_REAL`,
|
---|
| 167 | :const:`signal.ITIMER_VIRTUAL` or :const:`signal.ITIMER_PROF`) specified
|
---|
| 168 | by *which* to fire after *seconds* (float is accepted, different from
|
---|
| 169 | :func:`alarm`) and after that every *interval* seconds. The interval
|
---|
| 170 | timer specified by *which* can be cleared by setting seconds to zero.
|
---|
| 171 |
|
---|
| 172 | When an interval timer fires, a signal is sent to the process.
|
---|
| 173 | The signal sent is dependent on the timer being used;
|
---|
| 174 | :const:`signal.ITIMER_REAL` will deliver :const:`SIGALRM`,
|
---|
| 175 | :const:`signal.ITIMER_VIRTUAL` sends :const:`SIGVTALRM`,
|
---|
| 176 | and :const:`signal.ITIMER_PROF` will deliver :const:`SIGPROF`.
|
---|
| 177 |
|
---|
| 178 | The old values are returned as a tuple: (delay, interval).
|
---|
| 179 |
|
---|
| 180 | Attempting to pass an invalid interval timer will cause an
|
---|
| 181 | :exc:`ItimerError`. Availability: Unix.
|
---|
| 182 |
|
---|
| 183 | .. versionadded:: 2.6
|
---|
| 184 |
|
---|
| 185 |
|
---|
| 186 | .. function:: getitimer(which)
|
---|
| 187 |
|
---|
| 188 | Returns current value of a given interval timer specified by *which*.
|
---|
| 189 | Availability: Unix.
|
---|
| 190 |
|
---|
| 191 | .. versionadded:: 2.6
|
---|
| 192 |
|
---|
| 193 |
|
---|
| 194 | .. function:: set_wakeup_fd(fd)
|
---|
| 195 |
|
---|
| 196 | Set the wakeup fd to *fd*. When a signal is received, a ``'\0'`` byte is
|
---|
| 197 | written to the fd. This can be used by a library to wakeup a poll or select
|
---|
| 198 | call, allowing the signal to be fully processed.
|
---|
| 199 |
|
---|
| 200 | The old wakeup fd is returned. *fd* must be non-blocking. It is up to the
|
---|
| 201 | library to remove any bytes before calling poll or select again.
|
---|
| 202 |
|
---|
| 203 | When threads are enabled, this function can only be called from the main thread;
|
---|
| 204 | attempting to call it from other threads will cause a :exc:`ValueError`
|
---|
| 205 | exception to be raised.
|
---|
| 206 |
|
---|
[391] | 207 | .. versionadded:: 2.6
|
---|
[2] | 208 |
|
---|
[391] | 209 |
|
---|
[2] | 210 | .. function:: siginterrupt(signalnum, flag)
|
---|
| 211 |
|
---|
| 212 | Change system call restart behaviour: if *flag* is :const:`False`, system
|
---|
| 213 | calls will be restarted when interrupted by signal *signalnum*, otherwise
|
---|
| 214 | system calls will be interrupted. Returns nothing. Availability: Unix (see
|
---|
| 215 | the man page :manpage:`siginterrupt(3)` for further information).
|
---|
| 216 |
|
---|
| 217 | Note that installing a signal handler with :func:`signal` will reset the
|
---|
| 218 | restart behaviour to interruptible by implicitly calling
|
---|
[391] | 219 | :c:func:`siginterrupt` with a true *flag* value for the given signal.
|
---|
[2] | 220 |
|
---|
| 221 | .. versionadded:: 2.6
|
---|
| 222 |
|
---|
| 223 |
|
---|
| 224 | .. function:: signal(signalnum, handler)
|
---|
| 225 |
|
---|
| 226 | Set the handler for signal *signalnum* to the function *handler*. *handler* can
|
---|
| 227 | be a callable Python object taking two arguments (see below), or one of the
|
---|
| 228 | special values :const:`signal.SIG_IGN` or :const:`signal.SIG_DFL`. The previous
|
---|
| 229 | signal handler will be returned (see the description of :func:`getsignal`
|
---|
| 230 | above). (See the Unix man page :manpage:`signal(2)`.)
|
---|
| 231 |
|
---|
| 232 | When threads are enabled, this function can only be called from the main thread;
|
---|
| 233 | attempting to call it from other threads will cause a :exc:`ValueError`
|
---|
| 234 | exception to be raised.
|
---|
| 235 |
|
---|
| 236 | The *handler* is called with two arguments: the signal number and the current
|
---|
| 237 | stack frame (``None`` or a frame object; for a description of frame objects,
|
---|
| 238 | see the :ref:`description in the type hierarchy <frame-objects>` or see the
|
---|
| 239 | attribute descriptions in the :mod:`inspect` module).
|
---|
| 240 |
|
---|
[391] | 241 | On Windows, :func:`signal` can only be called with :const:`SIGABRT`,
|
---|
| 242 | :const:`SIGFPE`, :const:`SIGILL`, :const:`SIGINT`, :const:`SIGSEGV`, or
|
---|
| 243 | :const:`SIGTERM`. A :exc:`ValueError` will be raised in any other case.
|
---|
[2] | 244 |
|
---|
[391] | 245 |
|
---|
[2] | 246 | .. _signal-example:
|
---|
| 247 |
|
---|
| 248 | Example
|
---|
| 249 | -------
|
---|
| 250 |
|
---|
| 251 | Here is a minimal example program. It uses the :func:`alarm` function to limit
|
---|
| 252 | the time spent waiting to open a file; this is useful if the file is for a
|
---|
| 253 | serial device that may not be turned on, which would normally cause the
|
---|
| 254 | :func:`os.open` to hang indefinitely. The solution is to set a 5-second alarm
|
---|
| 255 | before opening the file; if the operation takes too long, the alarm signal will
|
---|
| 256 | be sent, and the handler raises an exception. ::
|
---|
| 257 |
|
---|
| 258 | import signal, os
|
---|
| 259 |
|
---|
| 260 | def handler(signum, frame):
|
---|
| 261 | print 'Signal handler called with signal', signum
|
---|
| 262 | raise IOError("Couldn't open device!")
|
---|
| 263 |
|
---|
| 264 | # Set the signal handler and a 5-second alarm
|
---|
| 265 | signal.signal(signal.SIGALRM, handler)
|
---|
| 266 | signal.alarm(5)
|
---|
| 267 |
|
---|
| 268 | # This open() may hang indefinitely
|
---|
| 269 | fd = os.open('/dev/ttyS0', os.O_RDWR)
|
---|
| 270 |
|
---|
| 271 | signal.alarm(0) # Disable the alarm
|
---|
| 272 |
|
---|