`asyncio` thread-safety issues in the free-threaded build

[colesbury]

Bug report

1. fi_freelist isn't thread-safe (move to pycore_freelist.h and follow that pattern)
2. enter_task, leave_task, and swap_current_task aren't thread-safe due to shared state->current_tasks and borrowed references.
3. register_task and unregister_task aren't thread-safe due to shared state->asyncio_tasks linked list
4. _asyncio_all_tasks_impl isn't thread-safe due the the asyncio_tasks linked list.

For 2, 3, and 4, we can consider using critical sections to protect the accesses to state->current_tasks and state->asyncio_tasks.

Longer term, moving data to per-loop will probably help with multi-threaded scaling.

Linked PRs

• gh-120974: Use common freelist code in asyncio #122132
• gh-120974: Make _asyncio._enter_task atomic in the free-threaded build #122138
• gh-120974: Make _asyncio._leave_task atomic in the free-threaded build #122139
• [3.13] gh-120974: Make _asyncio._enter_task atomic in the free-threaded build (GH-122138) #122152
• [3.13] gh-120974: Make _asyncio._leave_task atomic in the free-threaded build (GH-122139) #122186
• gh-120974: Make asyncio swap_current_task safe in free-threaded build #122317
• [3.13] gh-120974: Make asyncio swap_current_task safe in free-threaded build (GH-122317) #122612
• GH-120974: make _asyncio_all_tasks_impl thread safe #122801

[kumaraditya303]

I think that the pure Python fallback isn't thread safe either, FWIW I think there are more thread safety issues than these, asyncio code was written with assumption of GIL.

[corona10]

asyncio code was written with assumption of GIL.

Yeah, but for landing PEP 703, we are trying to change modules, not depending on the GIL, even if we need to re-write some parts of the implementation with a conditional flag. (If the new written part requires some performance overhead)