Skip to content

Commit 2dcf46e

Browse files
committed
Rewrite a sentence to be more in line with the rest of the documentation with
regard to person and audience.
1 parent bcddf67 commit 2dcf46e

1 file changed

Lines changed: 7 additions & 7 deletions

File tree

Doc/c-api/init.rst

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -492,13 +492,13 @@ thread could immediately acquire the lock and store its own thread state in the
492492
global variable). Conversely, when acquiring the lock and restoring the thread
493493
state, the lock must be acquired before storing the thread state pointer.
494494

495-
Why am I going on with so much detail about this? Because when threads are
496-
created from C, they don't have the global interpreter lock, nor is there a
497-
thread state data structure for them. Such threads must bootstrap themselves
498-
into existence, by first creating a thread state data structure, then acquiring
499-
the lock, and finally storing their thread state pointer, before they can start
500-
using the Python/C API. When they are done, they should reset the thread state
501-
pointer, release the lock, and finally free their thread state data structure.
495+
It is important to note that when threads are created from C, they don't have
496+
the global interpreter lock, nor is there a thread state data structure for
497+
them. Such threads must bootstrap themselves into existence, by first
498+
creating a thread state data structure, then acquiring the lock, and finally
499+
storing their thread state pointer, before they can start using the Python/C
500+
API. When they are done, they should reset the thread state pointer, release
501+
the lock, and finally free their thread state data structure.
502502

503503
Beginning with version 2.3, threads can now take advantage of the
504504
:cfunc:`PyGILState_\*` functions to do all of the above automatically. The

0 commit comments

Comments
 (0)