René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"\"mem\" and \"object\" Allocators are No Longer Protected by the GIL","articleBody":"Once we moved to per-interpreter GIL, the promises in [the docs](https://docs.python.org/3.12/c-api/memory.html#allocator-domains) no longer hold:\r\n\r\n```\r\n...where the allocation must be performed with the GIL held.\r\n```\r\n\r\nIt's still fine for pymalloc, but any custom, non-wrapping \"mem\"/\"object\" allocators would need to be updated to be thread-safe or per-interpreter.\r\n\r\nI have a PR up that does an okay job of adapting such allocators: gh-105619.  However, it penalizes use of such an allocator in subinterpreters that have their own GIL.\r\n\r\nHonestly, I'm leaning toward documenting that such allocators must be thread-safe or per-interpreter.  From what I understand, the documented guarantees (in the docs and in PEP 445) are more about representing what pymalloc needs than what custom allocators need.\r\n\r\nPerhaps the biggest question is: what projects would be impacted?  I haven't had a chance yet to search for projects that use custom mem/object allocators that aren't thread-safe.  I suspect there aren't more than two or three.\n\n\u003c!-- gh-linked-prs --\u003e\n### Linked PRs\n* gh-107519\n* gh-107522\n* gh-109035\n\u003c!-- /gh-linked-prs --\u003e\n","author":{"url":"https://github.com/ericsnowcurrently","@type":"Person","name":"ericsnowcurrently"},"datePublished":"2023-06-14T01:24:06.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":3},"url":"https://github.com/105766/cpython/issues/105766"}