16.10 Using SWIG-Generated Modules in a Multithreaded Environment

Credit: Joseph VanAndel, Mark Hammond

16.10.1 Problem

You want to use SWIG-generated modules in a multithreaded environment; therefore, the C code in these modules must release the Python global interpreter lock.

16.10.2 Solution

Use a typemap for SWIG (written by Mark Hammond) as posted on comp.lang.python. It maps Win32 API functions that return BOOL to Python functions that return None, but may raise exceptions. The wrapped function must set the standard Windows global LastError if it returns false (indicating that it has detected an error). The wrapping function must also automatically release the Python global interpreter lock for the duration of the function, and thus allow free multithreading.

%typedef BOOL BOOLAPI

%typemap(python,except) BOOLAPI {
        Py_BEGIN_ALLOW_THREADS
        $function
        Py_END_ALLOW_THREADS
        if (!$source)  {
              $cleanup
               return PyWin_SetAPIError("$name");
        }
}

16.10.3 Discussion

To use multiple threads effectively, you must release the Python global interpreter lock from your extension C code whenever feasible. The simplest way to do this with SWIG is to use an except directive, as shown in the recipe's typemap. Another interesting effect of this typemap is that it turns the C-oriented error-return convention (returning a 0 value and setting a global error indicator code) into a highly Pythonic convention (raising an exception).

16.10.4 See Also

SWIG and its typemaps are documented at http://www.swig.org; Windows API documentation on LastError available from Microsoft (http://msdn.microsoft.com).