A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2001-September/017496.html below:

[Python-Dev] Preventing PyEval_AcquireLock deadlock

[Python-Dev] Preventing PyEval_AcquireLock deadlock [Python-Dev] Preventing PyEval_AcquireLock deadlockGuido van Rossum guido@python.org
Fri, 14 Sep 2001 16:40:51 -0400
> Is there an easy way in the API to check if the current thread already has
> the interpreter lock so I can avoid calling PyEval_AcquireLock again?  If
> so, is it available all the way back to 1.5.2?

I don't think so.  It's easy to check whether *some* thread has the
lock, but the lock abstraction doesn't have a notion of ownership by a
specific thread.

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.

--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