I see. Well I was hoping to see the same result in the multiprocessing
example as using the threading example. What you pointed out makes sense
though, but what I don't understand is how modifying the queue in the
example works fine in both. Possibly it was designed for that kind of use?
Brandon L. Harris
On 07/15/2011 03:55 PM, Lee Harr wrote:
I'm working on a tool that runs a number of process is separate thread.
I've, up to this point, been using threading.Thread, but from what I
read multiprocess will allow multiple processors to be used
From the python docs on multiprocessing.
<Due to this, the multiprocessing module allows the programmer to fully
leverage multiple processors on a given machine.>
I have run into an issue when modifying the thread object from the run
method. Threading.thread allows me to change an attribute in the run
method and it hold while multiprocessing.Process loses it.
I am not a multiprocessing expert, but I think the problem you
are having is that Process is running your code in a separate
process, so there is no way you could see those object changes
in your main line code.
In other words, Process is not an exact replacement for Thread.
If you need to communicate between the different parts, you
would want to use the abstractions provided by Queue or Pipe.
Keep reading down the multiprocessing page in the docs until
you get to "Exchanging objects between processes":
http://docs.python.org/library/multiprocessing.html#exchanging-objects-between-processes
"Sharing state between processes" seems like it will be especially
relevant to what you are doing:
http://docs.python.org/library/multiprocessing.html#sharing-state-between-processes
Basically, it says "don't do that" :o)
Here is an example illustrating the inconsistency that I've seen.
One thing that would help here is a sample of what output
you get from your code, and what you were hoping to get.
--
http://mail.python.org/mailman/listinfo/python-list
