
"Martin v. Löwis" <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.
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. -- David Abrahams dave@boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution