[SciPy-user] Multithreading cookbook entry

Robert Kern robert.kern at gmail.com
Thu Feb 21 19:38:19 EST 2008


On Thu, Feb 21, 2008 at 6:02 PM, Lou Pecora <lou_boog2000 at yahoo.com> wrote:
>
>  --- Thomas Heller <theller at ctypes.org> wrote:
>
>  > Of course does ctypes release the GIL on foreign
>  > function calls.  And the GIL
>  > is acquired if Python implemented callback functions
>  > call back into
>  > Python code.
>
>  I'm sorry, I don't understand what you just said.  Can
>  you restate it?  I will also check the ctypes docs.

ctypes releases the GIL when it calls a C function. Some C functions
take callbacks; ctypes lets you pass Python functions as these
callbacks. There is a C stub wrapped around the Python function to
handle the communication. This stub reacquires the GIL before calling
the Python function.

>  > There is nothing that ctypes needs to know about the
>  > C function - if the
>  > C function is not thread safe, you must not call it
>  > from other threads.
>
>  How do I tell if the C function is thread safe?

You have to analyze the C function and the way you are calling it.
It's not necessarily an easy thing. Basically, you have to make sure
that concurrent calls to your functions don't touch the same data.

>  > Except - if the C function makes Python api calls,
>  > however, the GIL must not be
>  > released.  In this case you should use the Python
>  > calling convention; for details
>  > look up the docs (pydll and such).
>
>  My C function will make NO Python API calls. Can I
>  just call the Py_BEGIN_ALLOW_THREADS and
>  Py_BEGIN_ALLOW_THREADS macros in the C function to
>  allow return to another thread while the C function
>  calculates?

With ctypes, this is not necessary.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco



More information about the SciPy-User mailing list