Feature or enhancement

Proposal:

--disable-gil builds use critical sections more and more. In some cases a critcal section is held and will be re-entered immediately by the calling thread and this can be hard to avoid (e.g when we're going from C code to Python code back into related C code). Some examples of this are flushing I/O and calculating the MRO on a metaclass.

When this happens we treat this as re-entrancy to the critical section, and send it off to the parking lot to be released and then re-acquired. This can greatly slow down something which should just simply re-acquire the lock.

It's not super straight forward as we still need to support detaching and resuming the critical section in other cases of contention correctly for the lock.

As part of this it'd be good to also have the ability to collect stats on how often this is happening as we do want to generally avoid it and prefer lock-free paths where possible.

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

Linked PRs

• gh-114203: Optimise simple recursive critical sections #128126
• gh-114203: skip locking if object is already locked by two-mutex critical section #141476
• [3.14] gh-114203: skip locking if object is already locked by two-mutex critical section (GH-141476) #141564