Using signal.alarm to terminate a thread

Nick Craig-Wood nick at
Tue Nov 14 12:30:06 CET 2006

Adrian Casey <adrian.casey at> wrote:
> > Adrian Casey <adrian.casey at> wrote:
> > import os, pexpect, threading
> > 
> > def runyes():
> >         print "Running yes command..."
> >'yes', timeout=5)
> > 
> > t = threading.Thread(target=runyes)
> > t.start()
> > t.join()
> > 
>  The timeout parameter will not work in this case.  If you run the sample
>  code above, it will run forever.

The above runs just fine for me, stopping after 5 seconds.  Did you
try it?

>  The 'yes' command presents a class of command which can not be
>  easily be handled by pexpect.

Worked for me under Debian/testing.

> As far as I know, mixing threads and signals is OK provided the
> parent creates the alarm.

There are so many pitfalls here that I advise you not to try.  From
the linuxthreads FAQ

  J.3: How shall I go about mixing signals and threads in my program?

  The less you mix them, the better. Notice that all pthread_*
  functions are not async-signal safe, meaning that you should not
  call them from signal handlers. This recommendation is not to be
  taken lightly: your program can deadlock if you call a pthread_*
  function from a signal handler!

  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.

  Another option is to do nothing in the signal handler, and dedicate
  one thread (preferably the initial thread) to wait synchronously for
  signals, using sigwait(), and send messages to the other threads

Note also that the signal can be delivered to any thread which
complicates things.

Nick Craig-Wood <nick at> --

More information about the Python-list mailing list