gh-110693: Use a Linked List for Pending Calls

[ericsnowcurrently]

We do the following:

• update struct _pending_calls to use a linked list
• "allocate" the first 32 entries from a pre-allocated array
• (effectively) drop the limit on number of pending calls (but keep the currently limit of 32 for _PyRuntime.ceval.main_pending)

(This is a variation of gh-11122.)

• Issue: The Limit of 32 Pending Calls is Too Small #110693

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @ericsnowcurrently for commit bc284be 🤖

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

[gvanrossum]

Could you find a different reviewer instead of me? Maybe @colesbury? I have not looked at any of this stuff in ages -- feels like decades.

[markshannon]

This seems like it will make calls beyond the 32 quite expensive, as each request will require an allocation and a deallocation, beyond the existing cost.

Is having a fixed size list a problem in practice, or is it just that 32 items is too few?
Using an extra couple of kbs per interpreter is not a problem, if a limit of a few hundred would be OK.

If you are going to go with a linked list, I'd suggest dropping the array and only using a linked list, to simplify the code.
By reusing the links rather than freeing them, the performance impact should be negligible.

Maybe add a hard limit of a few thousand for safety?

[ericsnowcurrently]

Is having a fixed size list a problem in practice, or is it just that 32 items is too few?

too few

Using an extra couple of kbs per interpreter is not a problem, if a limit of a few hundred would be OK.

Good point. It just isn't clear what is a safe number. The problem is that if you've hit the max then currently _Py_AddPendingCall() silently throws away the one you're trying to add. It would be a different story if we did something like block until a spot in the array became available.

If you are going to go with a linked list, I'd suggest dropping the array and only using a linked list, to simplify the code. By reusing the links rather than freeing them, the performance impact should be negligible.

Agreed. The only catch is that the signal machinery uses pending calls as a fallback in certain cases. Starting off the freelist with a handful of preallocated items helps avoid problems. That said, I've done it a slightly different way that I think is less intrusive.

Maybe add a hard limit of a few thousand for safety?

You mean drop the current limit (INT32_MAX) down a bunch? I'd be fine with that.