Adam Reichold

> The error does not occur when using global thread pool instead of local one. Rayon is not involved at all, just spawning a thread which exits before the main...

Ok, I think I better understand this now and it appears that the global reference pool is the culprit: After returning from `test`, we have 16 reference count increments and...

@Crispy13 Could you try using a Git dependency for PyO3 based on the branch proposed in #4106? For example, using ```toml pyo3 = { git = "https://github.com/PyO3/pyo3.git", branch = "apply-pending-refcnt-updates-before-release",...

As a workaround for your existing code base, you can wrap all of your Rayon invocations with [`Python::allow_threads`](https://docs.rs/pyo3/latest/pyo3/marker/struct.Python.html#method.allow_threads) which should give you a stable application without any dependency changes.

> calling tp_dealloc for this pyclass calls GILPool::new which calls update_counts This happens because you use a `#[pyclass]` for the test, right? If you elide the `dropped` flag and use...

> make the reference pool update more algorithmically complex by identifying such pairs and eliding reference count operations involving them I don't think this will work as we cannot rely...

Considering the loopholes, its performance impacts and the possibility of solving this problem via a cooperating GILless Python interpreter, I fear we need to drop the reference pool unconditionally. I...

> Clone is convenient, and I now believe is fundamentally incorrect to defer without the GIL I agree that we should not try to defer reference count updates. I think...

I see two problems: We do not control all reference count updates as some will have through Python/C code instead of our code paths. And this would undo the performance...

> Sadly, In my case, this didn't solve the error. You could give #4095 a try if you feel adventurous. But the semantics are different and you probably need to...