Tim Peters <tim.one@comcast.net> writes: > I agree it should change, but doubt this rephrasing would help much. Do a > Google search on "free threading", and you'll find that all the top hits are > about Microsoft, or about Python (thanks to GregS and MarkH importing this > MS terminology into PythonLand). People on other OSes aren't likely to have > a clue what it means. True. I think I'll add a footnote as well. > For most people, I believe "thread safe" means that a collection of API > calls is safe to make without any special dances. For example, under some > Unix flavors, routines whose names end with _r are the "thread safe" > versions of routines without the trailing _r. Actually, Unix people tend to call those "re-entrant"; this is what the _r suffix suggests, anyway. It is almost correct to say that the Python API is not re-entrant. However, traditionally, this term was defined as "re-enter the function while it is being running". In this definition, the Python API *does* support certain kinds of reentrancy, namely those where the API is re-entered from the same thread. > Under that meaning (which I believe Guido also had in mind when he wrote > this section), Python's C API is indeed not thread-safe. We don't have to > apologize for that, though, we just have to spell out what's needed in the > presence of threads. This request was triggered by a question from c.l.p: "When will Python be thread-safe". It was not obvious that the poster was referring to the API docs, so the initial responses all were "Python *is* thread-safe". Regards, Martin
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