Eric Snow <ericsnowcurren...@gmail.com> added the comment:
Here are some solutions that I've considered:
1. immutable objects
a. make the objects truly immutable/const
* not trivial, if possible
b. make the objects effectively immutable
* (see GH-24828) use a really high refcount to make races irrelevant
2. per-interpreter objects
a. replace them with macros that do a per-interpreter lookup
b. replace them with simple placeholders and do a per-interpreter lookup
internally
c. replace them with PyObject placeholders and do a per-interpreter lookup
internally
As far as I'm aware, only (1b) and (2c) are realistic and won't break the
stable ABI (i.e. preserve layout).
(FWIW, I think that even with (1b) we would still have per-interpreter objects.)
-- Regarding (1a) --
See see GH-24828 for an example implementation. This includes storing some
state for the objects in PyInterpreterState and doing a lookup internally.
pros:
* relatively straightforward to implement
* overlaps with other interests (see bpo-40255)
* makes the objects shareable between interpreters (making them more efficient)
cons:
* we have to ensure the objects stay immutable (a tractable problem if the
solution is constrained to only the limited API objects)
-- Regarding (2c) --
This involves adding an API to get the per-interpreter object for a given
identity value (flag, global, etc.) and then mapping the limited API objects to
the corresponding per-interpreter ones.
pros:
* avoids a one-off solution
* extensions can stop using the variables directly (in favor of the new lookup
API)
cons:
* effectively couples the C-API to the design (as long as the objects are in
the limited API)
* many touches all over the C-API
* any future changes/additions in the C-API must deal with the objects
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue43503>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
