> ... > Hmm, so maybe we're not after lists after all: maybe what > we need is access to the global interpreter lock in Python, > so that we can write: > > sys.lock.acquire() > if list: > obj = list.pop() > else: > obj = default > sys.lock.release() The thread attempting the sys.lock.acquire() necessarily already owns the global lock, so the attempt to acquire it is a guaranteed deadlock -- arguably not helpful <wink>. > Or maybe we need some general lock in the thread module for these > purposes... don't know. It's been some time since I used > threads. Jim could easily allocate a list lock for this purpose if that's what he wanted; and wrap it in a class with a nice interface too. He'd eventually end up with the std Queue.py module, though. But if he doesn't want the overhead of an exception when the queue is empty, he sure doesn't want the comparatively huge overhead of a (any flavor of) lock either (which may drag the OS into the picture). There's nothing wrong with wanting a fast thread-safe queue! I just don't like the idea of adding an otherwise-ugly new gimmick to core lists for it; also have to wonder about Jim's larger picture if he's writing stuff in Python that's *so* time-critical that the overhead of an ordinary exception from time to time is a genuine problem. The verbosity of the alternative can be hidden in a lock-free class or function, if it's the clumsiness instead of the time that's grating.
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