home *** CD-ROM | disk | FTP | other *** search
- <TITLE>signal -- Python library reference</TITLE>
- Next: <A HREF="../s/socket" TYPE="Next">socket</A>
- Prev: <A HREF="../o/optional_operating_system_services" TYPE="Prev">Optional Operating System Services</A>
- Up: <A HREF="../o/optional_operating_system_services" TYPE="Up">Optional Operating System Services</A>
- Top: <A HREF="../t/top" TYPE="Top">Top</A>
- <H1>7.1. Built-in Module <CODE>signal</CODE></H1>
- This module provides mechanisms to use signal handlers in Python.
- Some general rules for working with signals handlers:
- <P>
- <UL>
- <LI>• A handler for a particular signal, once set, remains installed until
- it is explicitly reset (i.e. Python emulates the BSD style interface
- regardless of the underlying implementation), with the exception of
- the handler for <CODE>SIGCHLD</CODE>, which follows the underlying
- implementation.
- <P>
- <LI>• There is no way to ``block'' signals temporarily from critical
- sections (since this is not supported by all UNIX flavors).
- <P>
- <LI>• 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
- signals arriving during long calculations implemented purely in C
- (e.g. regular expression matches on large bodies of text) may be
- delayed for an arbitrary amount of time.
- <P>
- <LI>• 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.
- This is dependent on the underlying UNIX system's semantics regarding
- interrupted system calls.
- <P>
- <LI>• Because the C signal handler always returns, it makes little sense to
- catch synchronous errors like <CODE>SIGFPE</CODE> or <CODE>SIGSEGV</CODE>.
- <P>
- <LI>• Python installs a small number of signal handlers by default:
- <CODE>SIGPIPE</CODE> is ignored (so write errors on pipes and sockets can be
- reported as ordinary Python exceptions), <CODE>SIGINT</CODE> is translated
- into a <CODE>KeyboardInterrupt</CODE> exception, and <CODE>SIGTERM</CODE> is
- caught so that necessary cleanup (especially <CODE>sys.exitfunc</CODE>) can
- be performed before actually terminating. All of these can be
- overridden.
- <P>
- <LI>• 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
- threads simultaneously is: always perform <CODE>signal()</CODE> operations
- in the main thread of execution. Any thread can perform an
- <CODE>alarm()</CODE>, <CODE>getsignal()</CODE>, or <CODE>pause()</CODE>; 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 signal
- module, even if the underlying thread implementation supports sending
- signals to individual threads). This means that signals can't be used
- as a means of interthread communication. Use locks instead.
- <P>
- </UL>
- The variables defined in the signal module are:
- <P>
- <DL><DT><B>SIG_DFL</B> -- data of module signal<DD>
- This is one of two standard signal handling options; it will simply
- perform the default function for the signal. For example, on most
- systems the default action for SIGQUIT is to dump core and exit,
- while the default action for SIGCLD is to simply ignore it.
- </DL>
- <DL><DT><B>SIG_IGN</B> -- data of module signal<DD>
- This is another standard signal handler, which will simply ignore
- the given signal.
- </DL>
- <DL><DT><B>SIG*</B> -- data of module signal<DD>
- All the signal numbers are defined symbolically. For example, the
- hangup signal is defined as <CODE>signal.SIGHUP</CODE>; the variable names
- are identical to the names used in C programs, as found in
- <FILE>signal.h</FILE>.
- The UNIX man page for <FILE>signal</FILE> lists the existing signals (on
- some systems this is <FILE>signal(2)</FILE>, on others the list is in
- <FILE>signal(7)</FILE>).
- Note that not all systems define the same set of signal names; only
- those names defined by the system are defined by this module.
- </DL>
- <DL><DT><B>NSIG</B> -- data of module signal<DD>
- One more than the number of the highest signal number.
- </DL>
- The signal module defines the following functions:
- <P>
- <DL><DT><B>alarm</B> (<VAR>time</VAR>) -- function of module signal<DD>
- If <VAR>time</VAR> is non-zero, this function requests that a
- <CODE>SIGALRM</CODE> signal be sent to the process in <VAR>time</VAR> seconds.
- Any previously scheduled alarm is canceled (i.e. only one alarm can
- be scheduled at any time). The returned value is then the number of
- seconds before any previously set alarm was to have been delivered.
- If <VAR>time</VAR> is zero, no alarm id scheduled, and any scheduled
- alarm is canceled. The return value is the number of seconds
- remaining before a previously scheduled alarm. If the return value
- is zero, no alarm is currently scheduled. (See the UNIX man page
- <CODE>alarm(2)</CODE>.)
- </DL>
- <DL><DT><B>getsignal</B> (<VAR>signalnum</VAR>) -- function of module signal<DD>
- Return the current signal handler for the signal <VAR>signalnum</VAR>.
- The returned value may be a callable Python object, or one of the
- special values <CODE>signal.SIG_IGN</CODE>, <CODE>signal.SIG_DFL</CODE> or
- <CODE>None</CODE>. Here, <CODE>signal.SIG_IGN</CODE> means that the signal was
- previously ignored, <CODE>signal.SIG_DFL</CODE> means that the default way
- of handling the signal was previously in use, and <CODE>None</CODE> means
- that the previous signal handler was not installed from Python.
- </DL>
- <DL><DT><B>pause</B> () -- function of module signal<DD>
- Cause the process to sleep until a signal is received; the
- appropriate handler will then be called. Returns nothing. (See the
- UNIX man page <CODE>signal(2)</CODE>.)
- </DL>
- <DL><DT><B>signal</B> (<VAR>signalnum</VAR>, <VAR>handler</VAR>) -- function of module signal<DD>
- Set the handler for signal <VAR>signalnum</VAR> to the function
- <VAR>handler</VAR>. <VAR>handler</VAR> can be any callable Python object, or
- one of the special values <CODE>signal.SIG_IGN</CODE> or
- <CODE>signal.SIG_DFL</CODE>. The previous signal handler will be returned
- (see the description of <CODE>getsignal()</CODE> above). (See the UNIX
- man page <CODE>signal(2)</CODE>.)
- <P>
- When threads are enabled, this function can only be called from the
- main thread; attempting to call it from other threads will cause a
- <CODE>ValueError</CODE> exception to be raised.
- <P>
- The <VAR>handler</VAR> is called with two arguments: the signal number
- and the current stack frame (<CODE>None</CODE> or a frame object; see the
- reference manual for a description of frame objects).
- </DL>
-