Re: [LAD] Python assistance - threads (my favorite)

Is the program you're calling from popen generating any output on
stdin/stdout or waiting for input on stdin? Then there's a good chance
it's blocked and nothing happens.... so consider redirecting
stdin/stdout/stderr to /dev/null prior to calling the program out of
popen, or read/write the needed information from the process you are
calling. In contrast, the system() call will block the program it's
executing out of, but will blast it's I/O to that of the calling
program. Popen sends that input/output specifically to a pipe,and it
needs to be read/written to complete.

Also, consider what's actually happening when calling popen or system
-- a fork/exec (vfork usually). This may not be give the expected
results with multithreaded programming unless particular care is
taken. ( http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1287160467420+28353475&threadId=1438257
)

You're probably better off doing this kind of programming entirely
event-driven, without any use of threads. Instead of fork/exec, have a
subprocess that is basically a shell. Send text to it corresponding to
the program you want to execute, and then select() for activity on the
file descriptor which is either the program waiting for input or
generating output. Parse the output to determine if the program has
completed successfully, but do all of the processing asynchronously
and without blocking. Basically this ends up being a state machine
driven by the outputs (events) of the subprocesses being executed,
without ever blocking to await program completion.

This is the sort of thing best done by
http://www.nist.gov/el/msid/expect.cfm or the equivalent functionality
in python. Or the asynchronous subprocess facilities of WINTERP (
http://nielsmayer.com/winterp/doc/winterp.txt ), etc.

Niels
http://nielsmayer.com
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sat Oct 16 00:15:04 2010