[Michael Chermside]
> Please note that what was confusing the the original poster was
> almost certainly the docs saying that "Python" was not thread-safe
> when what was really intended was, as Tim points out, that Python's
> C api was not thread safe. Using the term "free threading" is fine,
> but also make it clear that it's the _C api_ we're talking about,
> because Python itself (ie, programs coded in pure Python) _IS_
> threadsafe.
Not really, under most meanings of "thread safe". For example,
"""
id = 0
def getid():
global id
id += 1
return id
"""
wouldn't be considered a thread-safe way to get an id by most people, but
"""
getid = iter(xrange(1, sys.maxint)).next
"""
would be. Thread safety is a complicated topic, in large part because
whether a chunk of code *is* "thread safe" can't be determined by staring at
it in isolation -- it can only be judged with respect to the specific
invariants a specific app relies on. The first version of getid() may in
fact be fine for a threaded app with unusually weak requirements.
That's why I'd rather explain the situation than try to reduce it to
buzzword compliance -- the buzzwords here don't have objective,
app-independent, universally accepted meanings.
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