Using signal.alarm to terminate a thread

I have a multi-threaded python application which uses pexpect to connect to
multiple systems concurrently. Each thread within my application is a
connection to a remote system. The problem is when one of the child
threads runs a command which generates an unlimited amount of output. The
classic example of this is the "yes" command. If you
execute "pexpect.run('yes')", your cpu will sit at 100% forever.

Here is a simple multi-threaded program using pexpect which demonstrates the
problem. The command 'yes' is run in a thread. The parent says that when
the alarm goes off, run the handler function. The thread sets the alarm to
trigger after 5 seconds.

Adrian Casey <ad**********@internode.on.netwrote:

> I have a multi-threaded python application which uses pexpect to connect
to
multiple systems concurrently. Each thread within my application is a
connection to a remote system. The problem is when one of the child
threads runs a command which generates an unlimited amount of output.
The
classic example of this is the "yes" command. If you
execute "pexpect.run('yes')", your cpu will sit at 100% forever.

Here is a simple multi-threaded program using pexpect which demonstrates
the
problem. The command 'yes' is run in a thread. The parent says that
when
the alarm goes off, run the handler function. The thread sets the alarm
to trigger after 5 seconds.

1) Don't ever mix threads and signals - you are heading for trouble!

2) pexpect has a timeout parameter exactly for this case

import os, pexpect, threading

def runyes():
print "Running yes command..."
pexpect.run('yes', timeout=5)

t = threading.Thread(target=runyes)
t.start()
t.join()

Adrian Casey <ad**********@internode.on.netwrote:
import os, pexpect, threading

def runyes():
print "Running yes command..."
pexpect.run('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 'yes' command presents a class of command which can not be
easily be handled by pexpect.

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

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.

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).

Adrian Casey <ad**********@internode.on.netwrote:

Adrian Casey <ad**********@internode.on.netwrote:
import os, pexpect, threading

def runyes():
print "Running yes command..."
pexpect.run('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
accordingly.

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

I'm running Kubuntu 06-06 with python 2.4.3 and the above code runs forever
at 100% cpu utilization.

>>import os, pexpect, threading
def runyes():

>>t = threading.Thread(target=runyes)
t.start()
Running yes command...

>>>

>>import os, pexpect, threading
def runyes():

>>t = threading.Thread(target=runyes)
t.start()
Running yes command...