Adrian Casey <[EMAIL PROTECTED]> wrote:
> > Adrian Casey <[EMAIL PROTECTED]> wrote:
> > 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.
--
Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick
--
http://mail.python.org/mailman/listinfo/python-list
