Simplify ReleasePool, remove parking_lot dependency.

[m-ou-se]

Replaces the parking_lot Mutex by a simple AtomicBool spinlock, and simplifies the ReleasePool to contain one Vec instead of pointers to two Vecs.

[m-ou-se]

@davidhewitt Since you wrote this part, can you review this?

I'm curious if there's any specific reason that I'm missing for why

• the UnsafeCells contained an *mut Vec instead of Vec,
• the pointers_being_dropped was contained within the ReleasePool,
• .set_len(0) was used instead of .clear().

This PR changes those things, but let me know if i'm missing something here. (In that case we should probably add a comment about it.)

[davidhewitt]

@m-ou-se thanks so much for all of the cleanups you have been pushing for pyo3 today!

The original two vector code existed long before me, though I was the most recent person to touch it up 😄 . My theory is that there were two reasons for this:

• While the pointers_to_drop mutex is locked, other Rust threads which might be dropping PyObjects or Py<T> might be blocked from making progress. In all honesty it seems like a very rare case that other threads would be doing anything with PyObjects at the same time, as no other thread would have the GIL.
• When the Py_DECREF call is made, arbitrary drop code can run, which might lead to further PyObject being dropped. It used to be the case before a recent change of mine that these PyObject would be put straight into the release pool. If the release pool Mutex was still locked then the thread would deadlock.

This second reason in particular forced the need for a two-vector solution, and would only hold the mutex while swapping between them so that the Py_DECREF calls could then be made without the mutex locked. (Using *mut Vec made it cheap to swap between the two vectors.)

But as I recently changed PyObjects to not use the release pool if the gil is held (see register_pointer function), this deadlock problem no longer applies. (Unless people are using the unsafe function assume_gil_aquired when pyo3 doesn't actually have any GILPool set. And they'll be getting much more noticeable crashes if they're doing that!)

As for set_len(0) - that's just something I missed in refactoring, using .clear() looks very sensible to me.

So, in summary, thanks for cleaning this up - I'm in favour of this change 👍

[kngwyu]

Thank you!
As @davidhewitt says, we need this simplification as the situtation changed.

[kngwyu]

Thanks for the update!

[programmerjake]

This pull request should have been changed to avoid spinlocks, see #916