On 2006-07-25 13:30:22, Carl J. Van Arsdall wrote: >> Running os.system() in multiple threads strikes me as kind of whacked. >> Won't they all compete to read and write stdin/stdout simultaneously? >> > Unfortunately this is due to the nature of the problem I am tasked with > solving. I have a large computing farm, these os.system calls are often > things like ssh that do work on locations remote from the initial python > task.
[...] > Again, the problem I'm trying to solve doesn't work like this. I've been > working on a framework to be run across a large number of distributed > nodes (here's where you throw out the "duh, use a distributed > technology" in my face). The thing is, I'm only writing the framework, > the framework will work with modules, lots of them, which will be > written by other people. Its going to be impossible to get people to > write hundreds of modules that constantly check for status messages. Doesn't this sound like a case for using processes instead of threads? Where you don't have control over the thread, you can use a process and get the separation you need to be able to kill this task. Alternatively you could possibly provide a base class for the threads that handles the things you need every thread to handle. They'd not have to write it then; they'd not even have to know too much about it. Gerhard -- http://mail.python.org/mailman/listinfo/python-list
