René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[subinterpreter] Make type version tag counter threadsafe for per interpreter GIL","articleBody":"The `next_version_tag` in `typeobject.c` is currently not thread safe and relies on GIL to protect against concurrent increments across threads. \r\n\r\nhttps://github.com/python/cpython/blob/63140b445e4a303df430b3d60c1cd4ef34f27c03/Objects/typeobject.c#L46-L50\r\n\r\n\r\nFor per-interpreter GIL, it must be made thread-safe otherwise the type cache will be affected by race conditions. Static types are not affected because they are immutable so this is a issue for pure Python classes aka heap types. This issue is for discussion of possible implementations.\r\n\r\n---\r\n\r\nPossible Solutions:\r\n- Make the `next_version_tag` counter per interpreter, while this may seems to fix the issue but since objects are shared across the interpreters and the type version tag is also used to represent a current state of a type in the specializing interpreter, two interpreters can have same the same tag for different types this won't work as expected.\r\n- Make the `next_version_tag` an atomic counter and increment it atomically using the `pyatomic APIs`. This is my preferred solution  since `next_version_tag` is only modified when a type is modified so is a rare operation and not a performance issue. Since this is just a counter `relaxed ordering` can be used here.\r\n\r\n\r\ncc @ericsnowcurrently \n\n\u003c!-- gh-linked-prs --\u003e\n### Linked PRs\n* gh-102343\n\u003c!-- /gh-linked-prs --\u003e\n","author":{"url":"https://github.com/kumaraditya303","@type":"Person","name":"kumaraditya303"},"datePublished":"2022-08-08T14:14:51.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":9},"url":"https://github.com/95795/cpython/issues/95795"}