At 11:01 PM 7/19/04 +0100, Paul Moore wrote:
> >> To contrast, list.append() does not claim thread safety.
> >
> > List operations like most C functions are also atomic.
>
>Thanks for that clarification. A note *somewhere* in the python-level
>documentation, stating that operations implemented in C are typically
>atomic, and so thread-safe, might be useful.
Perhaps it would be useful to point out that "safe" here means, "doesn't
corrupt the dictionary or crash Python". It doesn't mean "actually safe". :)
It would probably be "safest" not to describe anything as "thread safe",
but rather point out that in general, Python won't crash because a data
structure was accessed or altered by more than one thread, and that most
operations on most built-in types are atomic.
However, anything that calls back into Python code isn't necessarily
atomic, and in general, almost anything can call back into Python code.
For example, the seemingly harmless dictionary item assignment can call
back into Python for a custom type's __hash__ and __eq__ methods, so could
it be that a thread switch could actually occur during this statement:
foo[bar] = baz
if 'bar' has such custom methods? Maybe I'm wrong, and the GIL is still
held in such a case, but I'm not sure *how*.
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