Fix issue with PyObject drop and allow_threads

[davidhewitt]

While writing tests for #908 I realised unfortunately there is a bad interaction between the optimization I wrote in #851 and allow_threads.

With the GIL_COUNT method for gil_is_acquired, it's not possible to know if we are inside an allow_threads call without the GIL. The way #851 is currently written, in this situation we end up decreasing a reference count without the GIL held, which could cause all kind of bad stuff.

I propose to fix this situation by introducing a linked-list of GIL states, which is updated by both GILPool and allow_threads.

This fix is still broken if someone wishes to use the PyEval_SaveThread APIs themselves manually. If you think we need to worry about the case of users using PyEval_SaveThread themselves, then I think the only sensible solution is to revert #851.

I think the implementation here can still be cleaned up a lot. I wanted to open this PR to discuss the problem before I bothered to make the solution particularly tidy.

(I have also checked benchmarks and it does not noticeably affect performance.)

Let me know if you think I should finish this fix, or revert #851.

[kngwyu]

I'm sorry I don't completely understand the problem yet, but how about just setting it to zero?
E.g.,

        unsafe {
            let save = ffi::PyEval_SaveThread();
            let count = GIL_COUNT.with(|c| c.get());
            GIL_COUNT.with(|c| c.set(0));
            let result = f();
            GIL_COUNT.with(|c| c.set(count));
            ffi::PyEval_RestoreThread(save);
            result
        }

[davidhewitt]

Haha nice yes that will also solve the problem in a much simpler way! 😆

[davidhewitt]

Cool @kngwyu the simpler solution is much nicer 👍 👍 👍

(I've pushed that now, ready for you to review.)

[kngwyu]

Thank you!