gh-110693: Use a Larger Queue for Per-Interpreter Pending Calls (gh-118302)

This is an improvement over the status quo, reducing the likelihood of completely filling the pending calls queue.  However, the problem won't go away completely unless we move to an unbounded linked list or add a mechanism for waiting until the queue isn't full.

Author: ericsnowcurrently

Include/internal/pycore_ceval_state.h

@@ -20,7 +20,7 @@ struct _pending_call {
     int flags;
 };
 
-#define PENDINGCALLSARRAYSIZE 32
+#define PENDINGCALLSARRAYSIZE 300
 
 #define MAXPENDINGCALLS PENDINGCALLSARRAYSIZE
 /* For interpreter-level pending calls, we want to avoid spending too
@@ -31,7 +31,9 @@ struct _pending_call {
 #  define MAXPENDINGCALLSLOOP MAXPENDINGCALLS
 #endif
 
-#define MAXPENDINGCALLS_MAIN PENDINGCALLSARRAYSIZE
+/* We keep the number small to preserve as much compatibility
+   as possible with earlier versions. */
+#define MAXPENDINGCALLS_MAIN 32
 /* For the main thread, we want to make sure all pending calls are
    run at once, for the sake of prompt signal handling.  This is
    unlikely to cause any problems since there should be very few

Lib/test/test_capi/test_misc.py

@@ -1570,9 +1570,9 @@ def test_max_pending(self):
             self.assertEqual(added, maxpending)
 
         with self.subTest('not main-only'):
-            # Per-interpreter pending calls has the same low limit
+            # Per-interpreter pending calls has a much higher limit
             # on how many may be pending at a time.
-            maxpending = 32
+            maxpending = 300
 
             l = []
             added = self.pendingcalls_submit(l, 1, main=False)