[SciPy-user] odr thread safe?

Travis Oliphant oliphant@ee.byu....
Wed Mar 21 15:46:04 CDT 2007

Robert Kern wrote:

>Hmm. I'm not sure how this is happening. Calls to extension functions should be
>holding the global interpreter lock unless if it is explicitly released, and I'm
>pretty sure that I'm not. It's possible that the GIL gets released when the
>Python callbacks execute; I'd have to check. In that case, we would need a lock
>around the call to __odrpack.odr().
>But yeah, there's a difficult problem with calling a FORTRAN subroutine multiple
>concurrent times. We need to pass function pointer callbacks to the FORTRAN
>subroutine. These need to be real C functions. They can't have state, so the
>state needs to be global. C++ methods don't work. Consequently, the Python
>functions that the C callbacks will actually call are stored in odr_global.
>Looking at the Python C API docs, a possibility is to use
>PyThreadState_GetDict() to get a thread-specific dictionary. If threads aren't
>being used, then you only get NULL, though, so another mechanism will have to
>exist for the unthreaded case. I think. I could be misinterpreting the

In NumPy for the ufuncs, we use PyThreadState_GetDict and then if that 
is NULL use PyEval_GetBuiltins so that we always get a per-thread 
dictionary to store information in.

Something like that could be done.


>  http://docs.python.org/api/threads.html
>Let me know what you come up with!

More information about the SciPy-user mailing list