Home Original page

Which python libraries are thread-safe?

Tim Peters tim.one at home.com
Sat Oct 20 15:54:43 EDT 2001 
[Stuart D. Gathman]
> While python threads are simple and effective, how am I to know which
> library functions are thread safe and/or reentrant?

Experience <0.6 wink>.  The general rule-- which certainly has
exceptions --is that a library is threadsafe unless it explicitly says it's
not.  For example, random.py is not threadsafe and says so.  People keen on
threads are also especially urged to use the most recent release of Python,
as thread bugs across platforms can be exceedingly subtle and sometimes a
bug goes undetected for years.

> Do I have to carefully examine the source for each one, and wrap it
> in a lock if I am not convinced it is safe?

If you want to be certain of being safe, yes.

> Shouldn't this be a required part of the docs for any library module?

Sure, and if you're volunteering to submit doc patches, great; else it's
just another thing everyone is in favor of but not important enough to any
individual to make it to the top of their priority queue.  If you bump into
a problem, submit a bug report and/or patch to SourceForge; if everyone
would do just that much, the problem would have solved itself a long time
ago.

> A lot of modules have global state which is obviously a problem, but
> sometimes it is not clear.  Does tempfile work reliably with threads?

It was intended to, and there are no known tempfile thread issues in the
current tempfile.py.  The last thread bug in tempfile was found by Guido and
fixed by me on January 13; it was specific to Linux (or any OS that figures
it's a good idea for threads to have a process id different from the process
that spawned them).
More information about the Python-list mailing list