Gerhard Fiedler wrote: > 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 > > I'd be all for using processes but setting up communication between processes would be difficult wouldn't it? I mean, threads have shared memory so making sure all threads know the current system state is an easy thing. With processes wouldn't I have to setup some type of server/client design, where one process has the system state and then the other processes constantly probe the host when they need the current system state?
-- Carl J. Van Arsdall [EMAIL PROTECTED] Build and Release MontaVista Software -- http://mail.python.org/mailman/listinfo/python-list
