From 2dcf46ee2cddce17f18081ea7fa3535caad652dc Mon Sep 17 00:00:00 2001 From: Jeroen Ruigrok van der Werven Date: Sat, 25 Apr 2009 13:07:40 +0000 Subject: [PATCH] Rewrite a sentence to be more in line with the rest of the documentation with regard to person and audience. --- Doc/c-api/init.rst | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Doc/c-api/init.rst b/Doc/c-api/init.rst index e62bab6254b..281432b032e 100644 --- a/Doc/c-api/init.rst +++ b/Doc/c-api/init.rst @@ -492,13 +492,13 @@ thread could immediately acquire the lock and store its own thread state in the global variable). Conversely, when acquiring the lock and restoring the thread state, the lock must be acquired before storing the thread state pointer. -Why am I going on with so much detail about this? Because when threads are -created from C, they don't have the global interpreter lock, nor is there a -thread state data structure for them. Such threads must bootstrap themselves -into existence, by first creating a thread state data structure, then acquiring -the lock, and finally storing their thread state pointer, before they can start -using the Python/C API. When they are done, they should reset the thread state -pointer, release the lock, and finally free their thread state data structure. +It is important to note that when threads are created from C, they don't have +the global interpreter lock, nor is there a thread state data structure for +them. Such threads must bootstrap themselves into existence, by first +creating a thread state data structure, then acquiring the lock, and finally +storing their thread state pointer, before they can start using the Python/C +API. When they are done, they should reset the thread state pointer, release +the lock, and finally free their thread state data structure. Beginning with version 2.3, threads can now take advantage of the :cfunc:`PyGILState_\*` functions to do all of the above automatically. The