Carl J. Van Arsdall wrote: > 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. I suppose eventually I'll end up using a framework like twisted > but, as with many projects, I got thrown into this thing and threading > is where we ended up. So now there's the rush to make things work > before we can really look at a proper solution.
I don't get what threading and Twisted would to do for you. The problem you actually have is that you sometimes need terminate these other process running other programs. Use spawn, fork/exec* or maybe one of the popens. > 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. So, if I want my thread to "give itself up" I have to tell it > to give up. Threads have little to do with what you say you need. [...] > I feel like this is something we've established multiple times. Yes, we > want the thread to kill itself. Alright, now that we agree on that, > what is the best way to do that. Wrong. In your examples, you want to kill other processes. You can't run external programs such as ssh as Python threads. Ending a Python thread has essentially nothing to do with it. > Right now people keep saying we must send the thread a message. Not me. I'm saying work the problem you actually have. -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
