Movatterモバイル変換
[0]ホーム
[Python-Dev] Extension modules, Threading, and the GIL
David Abrahamsdave@boost-consulting.com
Sun, 29 Dec 2002 20:29:19 -0500
Recently an issue has come up on the C++-sig which I think merits alittle attention here. To boil it down, the situation looks likethis:Shared library Q uses threading but not Python. It supplies a aninterface by which users can supply callback functions. Some of thesecallbacks will be invoked directly in response to external calls intoQ; others will be invoked on threads started by calls into Q.Python extension module A calls shared library Q, but doesn't use itscallback interface. It works fine by itself.Python extension module B calls shared library Q and uses Q's callbackinterface. Because some of the callbacks need to use the Python API,and *might* be invoked by threads, they must all acquire the GIL.Because they also might be invoked by direct calls into Q, B mustalways release the GIL before calling anything in Q.Problem: using B while A is loaded breaks A: because B has installedcallbacks in Q that acquire the GIL, A must also release the GILbefore calling into Q.Notice that the author of A may have had no reason to believe anyonewould install Python callbacks in Q!It seems to me that for situations like these, where a function may ormay not be called on Python's main thread, it would be helpful ifPython supplied a "recursive mutex" GIL acquisition/release pair, forwhich acquisition and release on the main thread would simply bump acounter. Is this something that was considered and rejected?TIA,Dave-- David Abrahamsdave@boost-consulting.com *http://www.boost-consulting.comBoost support, enhancements, training, and commercial distribution
[8]ページ先頭