gh-76785: Expand How Interpreter Queues Handle Interpreter Finalization

[ericsnowcurrently]

Context

Any cross-interpreter mechanism for passing objects between interpreters must be very careful to respect isolation, even when the object is effectively immutable (e.g. int, str). Here this especially relates to when an interpreter sends one of its objects, and then is destroyed while the inter-interpreter machinery (e.g. queue) still holds a reference to the object.

When I added interpreters.Queue, I dealt with that case (using an atexit hook) by silently removing all items from the queue that were added by the finalizing interpreter.

Later, while working on concurrent.futures.InterpreterPoolExecutor (gh-116430), I noticed it was somewhat surprising when items were silently removed from the queue when the originating interpreter was destroyed. (See my comment on that PR.) It took me a little while to realize what was going on. I expect that users, which much less context than I have, would experience the same pain.

Solution

This is my approach to improving the situation. Users will now have three options:

1. return a singleton (interpreters.queues.UNBOUND) from Queue.get() in place of each removed item
2. raise an exception (interpreters.queues.ItemInterpreterDestroyed) from Queue.get() in place of each removed item
3. existing behavior: silently remove each item (i.e. Queue.get() skips each one)

The default will now be (1), but users can still explicitly opt in any of them, including to the silent removal behavior.

The behavior for each item may be set with the corresponding Queue.put() call. and a queue-wide default may be set when the queue is created. (This is the same as I did for "synconly".)

Other Options

Another option I looked at is, for each queue item from a finalizing interpreter, (1) copy the underlying data using the "raw" allocator, (2) release the object, and (3) deserialize like normal using the copied data. I tried this approach out but found it quickly got somewhat complex with tricky caveats and tabled exploring it further. It may still be worth doing but I'm going to start with the simpler options above.

I also considered something similar to option (1), but allowing any "shareable" object as the replacement rather than just interpreters.queues.UNBOUND. This also adds extra complexity and has, at best, hypothetical benefits, so I tabled it.

• Issue: [subinterpreters] PEP 554 implementation: add interpreters module #76785

[nineteendo]

What's the status here? Should you ask for someone to review it?

[ericsnowcurrently]

I'm planning on getting back to this in the next few weeks.

[ericsnowcurrently]

FYI, I'll probably do something similar for channels.

[miss-islington-app]

Thanks @ericsnowcurrently for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

[bedevere-app]

GH-121807 is a backport of this pull request to the 3.13 branch.