thread conditional code

[Robin Becker]

In article <mailman.987282680.10268.python-list at python.org>, Tim Peters
<tim.one at home.com> writes

Foreign threads can presumably do nasty things that even python locks
can't help.

>
>The periodic eval-loop "ticker checks" occur even if you compile Python
>without thread support.  So there is no way to avoid *that* "overhead".
>Fiddling with the global interpreter lock is just one of the things done
>inside the ticker-check block.  But when Python starts running, ceval.c's
>static interpreter_lock pointer is NULL, and the thread-switching code is
>skipped so long as it remains NULL.  The only way it can become non-NULL is
>if PyEval_InitThreads() gets called.  Python calls that itself when starting
>a new thread, and calling it is part of the dance foreign threads have to do
>if they want to call a Python C API function.  That's it.  Importing the
>thread or threading modules does *not* make it non-NULL, and neither does,
>e.g., allocating or even using (.release(), .acquire()) thread locks.  So the
>thread-switch jitterbug does not occur until Python knows that at least two
>threads exist.
...
I guess that answers my question; I can use locks without incurring any
unnecessary overhead by starting the jitterbug and at least I can
control access to contentious python objects. Foreign threads can do
what they want anyhow.

It would be good if one didn't have to dive into the code to learn this
sort of thing. Perhaps ordinary users really shouldn't be worrying about
such details, although of course they will.
-- 
Robin Becker