[Python-Dev] Extension modules, Threading, and the GIL

[David Abrahams]

"Martin v. L=F6wis" <martin@v.loewis.de> writes:

> David Abrahams wrote:
>> No, in fact there are several places where the API docs are
>> less-than-scrupulous about letting you know that your own event
>> dispatching hook may be re-entered during the call.  It's been a long
>> time since I've had the pleasure, but IIRC one of them happens in the
>> APIs for printing.
>
> It's unclear what you are talking about here. If you mean PrintDlgEx,
> then it very well documents that PRINTDLGEX.lpCallback can be
> invoked.

Well, as I said, it's been a long time, so I don't remember the
details.  However, let's assume it was PrintDlgEx for the time being.
If the caller of PrintDlgEx controls the contents of the PRINTDLGEX
structure, he can determine whether its lpCallback points to a
function that calls back into Python.  If it doesn't call back into
Python, he might reasonably presume that there's no need to release
the GIL.

He would be wrong. Lots of events can be dispatched to the application
before PrintDlgEx returns, so he needs to release the GIL if anything
in the application event handler can invoke Python.

AFAICT, this is typical for any Windows API function which the Windows
engineers thought might take a long time to return, and it's typically
not documented.

> In any case, it would be a bug in the wrapper to not release the GIL
> around calling PrintDlgEx.=20

You say tomato, I say documentation bug.

> Bugs happen and they can be fixed.

Yes.  This is an example of a kind of bug which is not uncommon, and
very hard to detect under some reasonable usage/development scenarios.
It might make sense to make Python immune to this kind of bug.

I think I'm done arguing about this.  If Mark isn't discouraged by
now, I'm still ready to help with the PEP.

--=20
                       David Abrahams
   dave@boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution