🤖 New build scheduled with the buildbot fleet by @ZeroIntensity for commit bdee2b2 🤖

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

Thanks for the thorough review!

For locked_deref, you might want to add an additional macro with an explicit return type instead instead of casting to a void **, say locked_deref_t(T, self). I didn't count how many usages of locked_deref need casting though so you might also inline those casts.

Acknowledged. I'll look at the cases.

Now, AFAICT, most of the changes can be written within a critical section because, except perhaps some of them where the lock depends on something else? (I don't really use critical sections but AFAIK, critical sections are roughly equivalent to acquire the GIL and hence safe lock all current resources, right?)

Critical sections are just a per-object locking mechanism, but they're safe against lock-ordering and re-entrancy deadlocks, because a thread's active locks are released when the thread state is detached (generally in a Py_BEGIN_ALLOW_THREADS block).

I could try and do this with a critical section, but it significantly complicates the change, because nearly every function that touches b_ptr will need a wrapper function that surrounds it with the critical section. I don't think that a critical section is worth the hassle, because all of the cases here are not re-entrant (at least under normal circumstances). If we're really worried about re-entrancy in something like PyBytes_FromStringAndSize, I think the better solution would be to create a copy of the pointer while the lock is still held, release the lock, and then call it with the new copy.