Using signal.alarm to terminate a thread

[Nick Craig-Wood]

Fredrik Lundh <fredrik at pythonware.com> wrote:
>  Nick Craig-Wood wrote:
> 
> >   The only sensible things you can do from a signal handler is set a
> >   global flag, or call sem_post on a semaphore, to record the delivery
> >   of the signal. The remainder of the program can then either poll the
> >   global flag, or use sem_wait() and sem_trywait() on the semaphore.
> 
>  but that's exactly what Python's signal handlers do, right ?
> 
>  (the interpreter uses a "pending call" queue to collect events, and 
>  executes them from the interpreter main loop in a controlled
>  fashion).

Yes you are absolutely right

>From http://docs.python.org/lib/module-signal.html

    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 signal()
    operations in the main thread of execution. Any thread can perform
    an alarm(), getsignal(), or 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 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 inter-thread communication. Use locks instead.

-- 
Nick Craig-Wood <nick at craig-wood.com> -- http://www.craig-wood.com/nick