[Phillip J. Eby] > What's wrong with using (e.g. setting attributes on) > 'threading.currentThread()'? It's already implemented and available in 2.3 > (and numerous prior versions). Jim's interest here is speed. currentThread() is a Python-level function call, which invokes the platform spelling for getting a thread id, which is then used in a dict lookup to get the associated Thread object. The C API's PyThreadState_GetDict() has none of those expenses: a pointer to a thread-local dict is sitting in the current thread state struct, available cheaply from C but currently not available at all from Python. If you need to access thread-local values frequently, the overhead of the currentThread() approach can swamp the time spent doing useful work. Jim sees this in Zope3 machinery now. I expect we're also seeing it in the sandbox's Decimal.py (which needs to access thread-local context on every operation, indirects thru yet another layer of Python-level call to get at it).
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