Thread safety of the python API

[Stephen Ludin]

Here's maybe a better example.  Let's say I wanted to use the python
dictobject directly in my code (vesus some other c hash table or an
STL map)  since implementation is robust and efficient, not to mention
actively maintained.  This would require the use of PyObjects, such as
PyInt and PyString.  To create the intobject, I call PyInt_FromLong. 
Let's also assume that I am not sharing objects between threads, just
calling the API from multiple threads (e.g. creating intobject in
multiple threads).  Note that I am not embedding the interpreter, just
using the API.

>From what I am hearing, this is 'bad' and is not a valid use scenario
for the API.  It is not safe to have two threads simultaneously using
the Python API.  In order to make it safe, I need to get the GIL (or
some other global mutex) before I call PyInt_FromLong, and then
release it.  Is this correct?

Thanks for your responses, this is the information I needed.

Stephen


Tim Peters <tim.one at comcast.net> wrote in message news:<mailman.1047606711.31564.python-list at python.org>...
> [Stephen Ludin]
> > I am developing an application that I may want to make scriptable with
> > python.  If I do so I'd like to use the convenience of the Python API
> > in the rest of my application for containers and user defined method
> > dispatch.  I am concerned though about using the API in a
> > multit-hreaded program.
> 
> As you should be.  As a not-too-close reading of the Python/C API manual
> will reveal, almost all Python API functions require that the caller hold
> the global interpreter lock:
> 
>     http://www.python.org/doc/current/api/threads.html
> 
> The only exceptions are a handful of initialization and finalization
> functions, explicitly identified on that page.  Even the simplest API
> operations can cause disaster if the lock isn't held -- you don't have to
> search for subtleties, one unprotected Py_INCREF or Py_DECREF is enough to
> hose you.
> 
> Other than that, it's very robust <wink>.