More thread-safe GC (another version)

[cjdoris]

Another alternative to #520 and #529.

This version just changes the finalizer of Py (and PyObjectArray) objects to:

• Decref the pointer if the GIL is currently held.
• Re-attach the finalizer if the GIL is not currently held - so the GC will try to finalize it again in the future, hopefully on the correct thread next time.

It's a lot simpler - the PythonCall.GC module is basically blank now, with enable() and disable() being no-ops.

[ericphanson]

From the PyCall version: JuliaPy/PyCall.jl#883 (comment)

note it is likely to be called again very soon, and probably on the same thread

which could be problematic here. It doesn’t seem nice to have an infinite loop of finalizers, if they keep getting scheduled on the same thread.

To me some kind of queue makes the most sense. However probably anything is better than the segfaults of the status quo.

[cjdoris]

It doesn’t seem nice to have an infinite loop of finalizers, if they keep getting scheduled on the same thread.

Agreed, although it seems unlikely - I think for this to occur you'd have to be doing all your allocating on one thread (and for that not to be on the thread holding the GIL). I think the other approaches have a similar issue though. Maybe an explicit queue (as in #520 or #529) is indeed nicer.

I'll run some benchmarks and see if that helps decide.

[cjdoris]

Closing in favour of #529