Steve Dower <steve.do...@python.org> added the comment:
> Does it mean that a type A created in interperter 1 can be seen/accessed from > interpreter 2? No, but it means that a type A *knows* that it was created in interpreter 1 without relying on the current thread local storage. What it does with this information is totally independent :) > How about you add a module state reference to the type object and a > interpreter state reference to the module object? Module state != module object, IIUC, but a chain like: instance -> type -> module -> interpreter would be feasible, if an extra step. Though that's only if PEP 573 makes it *compulsory* for heap types to contain a pointer to their module. Without a pointer to the interpreter state, an object could lose access to its memory (de)allocator (or its lock), depending on the model we eventually use to reduce reliance on the GIL in subinterpreters. (Yes, this is one step in the direction of reducing the impact of the GIL, as well as reducing the tight coupling between native threads and Python threads, which is a huge pain point for embedders.) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue38160> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
