"Robert Brewer" <fumanchu at amor.org> wrote: > "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. *boggles* Perhaps there should be an entry in the documentation about this. Here is a proposed modification. Despite desires and assumptions to the contrary, <b>threading.local is not magic</b>. Placing references to global shared objects into threading.local <b>will not make them magically threadsafe</b>. Only by using threadsafe shared objects (by design with Queue.Queue, or by desire with lock.acquire()/release() placed around object accesses) will you have the potential for doing safe things. - Josiah
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