GIL in the new glossary

[David Abrahams]

"Tim Peters" <tim.one at comcast.net> writes:

> [Dave Kuhlman]
>> What about the implementer of a Python extension who only wants to
>> be *minimally* or moderately "blissfully unaware" of the GIL.  Is
>> there a list of n (n < 5) important things to do (or not do) in
>> order to enable the users of her/his extension obtain as much
>> parallelism as possible.
>
> There's only one critical rule involving the GIL: you must never
> call any piece of the Python C API (not even Py_INCREF!) without
> holding the GIL(*).

Well, I think there's another, subtler rule: if you're going to call a
function which acquires the GIL other than by the newly-proposed PEP
311 method (http://www.python.org/peps/pep-0311.html), you'd better
damn-well release the GIL first! I guess that's what your (*) is all
about.

> This severely limits your options to the point where it's pretty much
> obvious what you can and can't get away with.
>
>> For example, are any of the following good rules to follow?
>>
>> - Always release the GIL before I/O operations.
>
> Usually.  But if, for example, you're writing a single character to what you
> know is a local terminal, releasing the GIL is probably a waste of time.
> Common sense shouldn't go out the window.
>
>> - Always release the GIL at the beginning of and re-acquire it at
>>   the end of any sufficiently long lasting function.
>
> That's only possible if the function never invokes the Python C API,

...without re-acquiring the GIL first...

> and such functions are rare.  

I think it depends.  In typical wrapping C/C++ API jobs it's fairly
common.  In fact, it seems to be reasonably common that the function
(indirectly) calls some other function which acquires the GIL itself,
in order to access the Python 'C' API.



> (*) In which chapter you'll find the few exceptions to the "must hold
>     the GIL before calling" rule.  The chief exception is
>     PyEval_AcquireLock() -- if you hold the GIL when calling *that*,
>     the result is immediate deadlock <wink>.
>

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com