René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"enum_next and pairwise_next can result in tuple elements with zero reference count in free-threading build","articleBody":"# Bug report\n\n### Bug description:\n\nThe enumerate object (and also the `itertools.pairwise` since https://github.com/python/cpython/pull/118219) re-uses tuples when possible. It does this by checking the reference count to be 1:\n```c\n   // from enum_next in enumobject.c\n    if (Py_REFCNT(result) == 1) {\n        Py_INCREF(result);\n        old_index = PyTuple_GET_ITEM(result, 0);\n        old_item = PyTuple_GET_ITEM(result, 1);\n        PyTuple_SET_ITEM(result, 0, next_index);\n        PyTuple_SET_ITEM(result, 1, next_item);\n        Py_DECREF(old_index);\n        Py_DECREF(old_item);\n        ....\n```\nThe refcount check and increment are not atomic, so in the free-threading build multiple threads can end up operating on the `result` object. It is possible that one thread already sets an item in the tuple, and another thread decrefs the item believing it is still an old item.\n\nIn the nogil reference implementation (https://github.com/colesbury/nogil) no changes are made to address this. So maybe the issue cannot occur?\n\nIn https://github.com/python/cpython/pull/120591 this problem is addressed with a lock, which might be too much overhead (see the discussion in https://github.com/python/cpython/issues/120496)\n\n@colesbury @hauntsaninja\n\n### CPython versions tested on:\n\nCPython main branch\n\n### Operating systems tested on:\n\nWindows\n\n\u003c!-- gh-linked-prs --\u003e\n### Linked PRs\n* gh-125734\n\u003c!-- /gh-linked-prs --\u003e\n","author":{"url":"https://github.com/eendebakpt","@type":"Person","name":"eendebakpt"},"datePublished":"2024-07-07T19:59:45.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":4},"url":"https://github.com/121464/cpython/issues/121464"}