GIL in the new glossary

[Tim Peters]

[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(*).
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, and
such functions are rare.  As to whether it's desirable in those cases
depends entirely on the threaded semantics you want to guarantee:  threads
are tricky to work with in C, and if you don't arrange for your own layer of
exclusion then around the data manipulated by the function (recalling that
you no longer have the GIL to rely on), you'll end up with anything from
non-deterministic operation to segfaults.

> ...
> And, conversely, is there a list of situations when it would be
> dangerous or counter-productive to release the GIL in an
> extension?

See the "one critical rule" above.

> I took a quick look at the "Extending and Embedding the Python
> Interpreter" document, and did not see anything about this.

The critical rule is covered in the "Initialization, Finalization, and
Threads" chapter of the Python/C API manual; the manuals talk about what's
necessary for sanity, not about the pragmatics of optimization without the
GIL (then in you're in perfectly general non-Python threaded programming
territory, and the Python manual has nothing to say about that).

(*) 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>.