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 fumanchu at amor.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20051011/39c9073f/attachment.html
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4