Added a comment about GIL acquisition vs. multithreading vs. program exit.

[smurfix]

I added a paragraph warning about this problem. Maybe it saves somebody else a few hours of work.

Cf. #890 where one of my problems was exactly this …

[wjakob]

What does "nor ignoring a cancellation" mean?

I will note that nb::is_alive() can be used to skip deallocation/destructor code in some cases. It's not so nice because that causes leaks, but still infinitely preferable to segfaults.

[smurfix]

When you try to acquire the GIL and Python is in shutdown, your thread self-cancels. You can't catch this exception without re-throwing it, the compiler won't let you.

I can't fix the problem by (only) calling is_alive in my own destructors because that's not sufficient if the object contains one of nanobind's. To that effect I created PR #894 which adds aliveness checks to all of nanobind's destructors if they directly acquire the GIL. I didn't yet check whether that's sufficient.

[wjakob]

Hi @smurfix,

sorry for the long delay in getting to this. The information in this message is not quite accurate anymore: the crashing behavior was changed in recent Python versions. The issue is also not in threads being alive in general -- it's threads that work with nanobind objects, and specifically in such a way that the GIL is dropped and reacquired (which is the step that crashes on old python versions, and pauses those threads on newer versions). Would you consider updating the text to make this more clear, or shall I close the PR?