Add missing "is_alive" checks before acquiring the GIL in destructors.

[smurfix]

cf. #891

[wjakob]

Could you add a changelog as well?

[smurfix]

Done.

We'll see whether that is sufficient …

[wjakob]

After some more thought, I don't think that this really fixes the issue.

While nb::is_alive() might return True when the condition is checked, there is no guarantee that this is still the case at the next instruction. Basically this is a race condition. If you want to avoid undefined behavior, you will need to prevent this problem in another way.

[smurfix]

That is true in general. But what happens when the Python program throws an uncaught exception or otherwise ends abnormally, or simply is signalled to end?

I'm not concerned with preventing a 0.1% chance of a hard coredump and whatnot due to a race condition in this case. I'm concerned with preventing a 100% chance of getting one.

[wjakob]

By having a condition variable, mutex, or similar synchronization mechanism, you can guarantee that the right order is enforced during shutdown. If the application is killed, then the kernel will shut things down and none of this code will run at all.

A crash that happens in 0.1% of runs is super annoying because it is so hard to reproduce. I would rather have software fail spectacularly than accumulate lots of issues in the long tail.

[smurfix]

On the other hand, in a program that does have mutexes and whatnot, this issue raises its ugly head only when an abnormal situation happens. In that case it transforms a reasonably-clean stacktrace and debug dump into an inconsistent ugly mess. Been there done that; with this patch applied I can at least get out of my debugging session without crashing or having to resort to "kill -9".

[wjakob]

-> https://discuss.python.org/t/safely-using-the-c-api-when-python-might-shut-down/78850