The Limit of 32 Pending Calls is Too Small

[ericsnowcurrently]

We currently have a limit of 32 pending calls for each interpreter. This has been the limit pretty much since pending calls were added (originally for signal handling). Now that we use pending calls between interpreters (e.g. to decref an object under the correct interpreter), a maximum of 32 is too low. This will become a bigger problem as subinterpreters are used more.

The current workaround looks something like this:

    while (_PyEval_AddPendingCall(interp, func, arg, flags) < 0) {
        // Keep trying until the pending calls is added.
    };

...perhaps also involving a separate queue or an extra thread.

Possible improvements:

• substantially increase the limit, e.g. to 500 (and keep using the statically allocated array)
• use a linked list with no limit
• use a linked list with some large limit (to prevent accidental out-of-control growth)
• use a linked list but "allocate" from a static array for the first 32 pending calls

(This issue is a continuation of gh-79647.)

Linked PRs

• gh-110693: Use a Linked List for Pending Calls #110694
• gh-110693: Pending Calls Machinery Cleanups #118296
• gh-110693: Use a Larger Queue for Per-Interpreter Pending Calls #118302
• gh-110693: Add a Timeout to _PyEval_AddPendingCall() #118329
• gh-110693: refactor pending calls and use linked list implementation #125567

[kumaraditya303]

I would go with a linked list implementation with no limits. I don't think limiting it has any benefit.

[ericsnowcurrently]

For 3.12 the simplest thing would be to bump NPENDINGCALLS from 32 to something really large (e.g. 1000), though that is a bit wasteful of memory. Backporting the linked list implementation might be okay too.

CC @Yhg1s

[gvanrossum]

(Maybe change the title to "... is Too Small"? "Few" sounds odd here. Also maybe don't use Title Caps. :-)