Author: Armin Rigo <ar...@tunes.org>
Branch:
Changeset: r97442:6cd7a0d1a940
Date: 2019-09-11 17:05 +0200
http://bitbucket.org/pypy/pypy/changeset/6cd7a0d1a940/
Log: CPython issue #38106
On OS X, call pthread_cond_signal() before pthread_mutex_unlock().
This should not make a difference, but does if another thread
notices that the lock is released and frees the lock---this is
possible at any time after the pthread_mutex_unlock(). We can't rely
on the condition variable 'lock->lock_released' to remain in
existence.
This can't occur on top of Python lock objects because of the GC,
but can occur by direct calls to the C API functions via cpyext.
diff --git a/rpython/translator/c/src/thread_pthread.c
b/rpython/translator/c/src/thread_pthread.c
--- a/rpython/translator/c/src/thread_pthread.c
+++ b/rpython/translator/c/src/thread_pthread.c
@@ -454,13 +454,13 @@
lock->locked = 0;
- status = pthread_mutex_unlock( &lock->mut );
- CHECK_STATUS("pthread_mutex_unlock[3]");
-
/* wake up someone (anyone, if any) waiting on the lock */
status = pthread_cond_signal( &lock->lock_released );
CHECK_STATUS("pthread_cond_signal");
+ status = pthread_mutex_unlock( &lock->mut );
+ CHECK_STATUS("pthread_mutex_unlock[3]");
+
return result;
}
_______________________________________________
pypy-commit mailing list
pypy-commit@python.org
https://mail.python.org/mailman/listinfo/pypy-commit
