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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4