comparison Python/pystate.c @ 69635:f6feed6ec3f9 2.7

Issue #10517: After fork(), reinitialize the TLS used by the PyGILState_* APIs, to avoid a crash with the pthread implementation in RHEL 5. Patch by Charles-François Natali.
author Antoine Pitrou <solipsis@pitrou.net>
date Wed, 27 Apr 2011 19:20:48 +0200
parents cd8d3c2d3bce
children ee4fe16d9b48
comparison
equal deleted inserted replaced
69588:8dbf661c0a63 69635:f6feed6ec3f9
535 { 535 {
536 PyThread_delete_key(autoTLSkey); 536 PyThread_delete_key(autoTLSkey);
537 autoInterpreterState = NULL; 537 autoInterpreterState = NULL;
538 } 538 }
539 539
540 /* Reset the TLS key - called by PyOS_AfterFork.
541 * This should not be necessary, but some - buggy - pthread implementations
542 * don't flush TLS on fork, see issue #10517.
543 */
544 void
545 _PyGILState_Reinit(void)
546 {
547 PyThreadState *tstate = PyGILState_GetThisThreadState();
548 PyThread_delete_key(autoTLSkey);
549 if ((autoTLSkey = PyThread_create_key()) == -1)
550 Py_FatalError("Could not allocate TLS entry");
551
552 /* re-associate the current thread state with the new key */
553 if (PyThread_set_key_value(autoTLSkey, (void *)tstate) < 0)
554 Py_FatalError("Couldn't create autoTLSkey mapping");
555 }
556
540 /* When a thread state is created for a thread by some mechanism other than 557 /* When a thread state is created for a thread by some mechanism other than
541 PyGILState_Ensure, it's important that the GILState machinery knows about 558 PyGILState_Ensure, it's important that the GILState machinery knows about
542 it so it doesn't try to create another thread state for the thread (this is 559 it so it doesn't try to create another thread state for the thread (this is
543 a better fix for SF bug #1010677 than the first one attempted). 560 a better fix for SF bug #1010677 than the first one attempted).
544 */ 561 */