Author: Alex Gaynor <[email protected]>
Branch:
Changeset: r45603:e62883bb9a0d
Date: 2011-07-14 17:23 -0700
http://bitbucket.org/pypy/pypy/changeset/e62883bb9a0d/
Log: Actually call the appropriate deallocation function on lock objects
when we're done with them, not just deallocate the struct that
contains them. It is extremely likely that they have some OS
resources assosciated with them.
diff --git a/pypy/module/thread/ll_thread.py b/pypy/module/thread/ll_thread.py
--- a/pypy/module/thread/ll_thread.py
+++ b/pypy/module/thread/ll_thread.py
@@ -21,6 +21,7 @@
'RPyThreadAcquireLock', 'RPyThreadReleaseLock',
'RPyThreadYield',
'RPyThreadGetStackSize', 'RPyThreadSetStackSize',
+ 'RPyOpaqueDealloc_ThreadLock',
'RPyThreadAfterFork']
)
@@ -52,6 +53,9 @@
c_thread_lock_init = llexternal('RPyThreadLockInit', [TLOCKP], rffi.INT,
threadsafe=False) # may add in a global list
+c_thread_lock_dealloc = llexternal('RPyOpaqueDealloc_ThreadLock', [TLOCKP],
+ lltype.Void,
+ threadsafe=True)
c_thread_acquirelock = llexternal('RPyThreadAcquireLock', [TLOCKP, rffi.INT],
rffi.INT,
threadsafe=True) # release the GIL
@@ -120,7 +124,7 @@
def __enter__(self):
self.acquire(True)
-
+
def __exit__(self, *args):
self.release()
@@ -156,6 +160,9 @@
return ll_lock
def free_ll_lock(ll_lock):
+ c_thread_acquirelock(ll_lock, 0)
+ c_thread_releaselock(ll_lock)
+ c_thread_lock_dealloc(ll_lock)
lltype.free(ll_lock, flavor='raw', track_allocation=False)
def acquire_NOAUTO(ll_lock, flag):
_______________________________________________
pypy-commit mailing list
[email protected]
http://mail.python.org/mailman/listinfo/pypy-commit
