Deadlock involving __dealloc__ about lupa HOT 3 CLOSED

Hmm, interesting case. That makes locking the runtime appear much less appealing inside of __dealloc__. It's difficult to avoid, though.

The lock that Lupa uses is re-entrant, so this rarely poses problems. It probably requires a setup as in your case to trigger it: passing Python objects over to other Lua threads inside of a Lua call.

One possible solution that comes to my mind is to request the lock in a non-blocking way in cases where we cannot afford waiting (in __dealloc__ specifically), and if we fail to acquire it, add the object to a list in the LuaRuntime and deallocate that list the next time right before we release the lock (i.e. when we definitely own it any way). That would probably keep some objects alive longer than necessary, and there might also be situations where this has other unexpected effects (we're dealing with threads here, so anything can happen, really), but it should still work as before in most cases and only behave differently in cases where it's currently dead-lock prone already. And probably provides an improvement in that case.

from lupa.

I agree with what you wrote, and I can contribute a test case which currently fails for me:

def test_lupa_gc_deadlock():

    def assert_no_deadlock(thread):
        thread.start()
        thread.join(1)
        assert not thread.is_alive(), "thread didn't finish"

    def trigger_gc(ref):
        del ref[0]

    lua = LuaRuntime()
    ref = [lua.eval("{}")]
    lua.execute(
        "f,x=...; f(x)",
        assert_no_deadlock,
        Thread(target=trigger_gc, args=[ref]),
    )

from lupa.

I started fixing this, but the test that you provided is still failing. Might just be a missing cleanup call somewhere.

See #255

from lupa.