Gordon McMillan wrote: > > M.-A. Lemburg writes: > > > True, sys.lock.acquire() would have to set a flag *not* to release > > the lock until the next call to sys.lock.release(), which then > > clears this flag again. Sort of a lock for the unlocking the lock > > ;-) > > > > Could this work, or am I having a mind twister somewhere in > > there again ? > > Sounds like a critical section to me. On Windows, those are > lightweight and very handy. You can build one with Python thread > primitives, but unfortunately, they come out on the heavy side. > > Locks come in 4 types, categorized by whether they can be released > only by the owning thread, and whether they can be acquired > recursively. The interpreter lock is in the opposite quadrant from a > critical section, so "sys.lock.freeze()" and "sys.lock.thaw()" have > little chance of having an efficient implementation on any platform. Actually, I think all that's needed is another global like the interpreter_lock in ceval.c. Since this lock is only accessed via abstract functions, I presume the unlock flag could easily be added. The locking section would only focus on Python, though: other threads could still be running provided they don't execute Python code, e.g. write data to a spooler. So it's not really the equivalent of a critical section as the one you can define in C. PS: I changed the subject line... hope this doesn't kill the thread ;) -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 158 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
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