Steve Holden wrote:
> The nice thing about Python threads (or rather threading.threads) is
> that since each thread is an instance it's *relatively* easy to ensure
> that a thread restricts itself to manipulating thread-local resources
> (i.e. instance members).
>
> This makes it possible to write algorithms parameterized for the number
> of "worker threads" where the workers are taking their tasks off a Queue
> with entries generated by a single producer thread. With care, multiple
> producers can be used. More complex inter-thread communications are
> problematic, and arbitrary access to foreign-thread state is a nightmare
> (although the position has been somewhat alleviated by the introduction
> of threading.local).
"Somewhat alleviated" and somewhat worsened. I've had half a dozen conversations in the last year about sharing data between threads; in every case, I've had to work quite hard to convince the other person that threading.local is *not* magic pixie thread dust. Each time, they had come to the conclusion that if they had a global variable, they could just stick a reference to it into a threading.local object and instantly have safe, concurrent access to it.
Robert Brewer
System Architect
Amor Ministries
[EMAIL PROTECTED]
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
