> > Let's take a step back. Why do you need this? I'm guessing that you > > have a C++ library that calls C++ callbacks, and now you want to call > > a Python callback from your C++ callback. The proper solution is to > > make sure that you *always* release the Python lock before entering > > your event loop or anything else that could possibly call callbacks. > > See _tkinter for how I handled it there. It's ugly, but possible. > > Yep, I've already got it working this way except there are a few > code paths that result in a callback sometimes being called > indirectly from a different part of the code where the Python lock > is already acquired. I was hoping to be able to use a general > solution instead of having to find all those situations and > special-case them. Oh well. I guess you could have your own global variable that says "I've already got the Python lock". The lock sequences would look like this: // before entering the event loop clear the flag unlock the GIL // after returning from the event loop lock the GIL set the flag --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4