gh-128415: store current task on loop

[kumaraditya303]

• Issue: Store current task on the loop in asyncio  #128415

[picnixz]

Some nits.

[picnixz]

Having "None" in the message could be a bit confusing. Perhaps something like "Leaving task %R does not match the current task (None)" or "Unexpected leaving task %R"?

[picnixz]

Maybe a module-level class would be better?

[picnixz]

Can you align this one?

[picnixz]

Suggested change

	raise RuntimeError(f"Cannot enter into task {task!r} while another "
	f"task {loop._current_task!r} is being executed.")
	raise RuntimeError(f"Cannot enter into task {task!r} while another "
	f"task {loop._current_task!r} is being executed.")

[picnixz]

Suggested change

	raise RuntimeError(f"Leaving task {task!r} does not match "
	f"the current task {loop._current_task!r}.")
	raise RuntimeError(f"Leaving task {task!r} does not match "
	f"the current task {loop._current_task!r}.")

[asvetlov]

Thank you for raising the issue!

Could you please consider an alternative implementation?
I would suggest adding a new class. BaseEventLoop already exists; let's name it _EventLoopHelpers for example.
The _EventLoopHelpers is a C extension class; it has current_tasks, non_asyncio_tasks, eager_tasks, and most notable asyncio_tasks_head. The last is not PyObject * but llist_node; it is not exposed to Python space.
BaseEventLoop is inherited from _EventLoopHelpers if available; otherwise, global objects from asyncio_state are used.
The proposed helper class is storage for placing all loop-scoped states; in the future, some time-critical methods like call_soon/call_later could be implemented in C if we decide to do it.
The proposed helper class is internal now; we can make it public for reuse by uvloop and others, but now it is out of the scope of the issue.
If a loop is not inherited from _EventLoopHelpers, the module-scoped already existing variables are used, as we have already done.

Thoughts?

[kumaraditya303]

The _EventLoopHelpers is a C extension class; it has current_tasks, non_asyncio_tasks, eager_tasks, and most notable asyncio_tasks_head. The last is not PyObject * but llist_node; it is not exposed to Python space.

That would work for things like the storing all the tasks and the eager tasks, but for current task one loop will only ever have one current task so all that isn't needed. Specifically I am saying the even for the loop scoped state we don't need current_tasks dict, a single attribute on loop works.

[asvetlov]

@kumaraditya303 sorry, I was inaccurate in my comment.
Yes, the only current task is needed instead of the dict after storing the current task in the loop.
I'm talking about a slightly different thing.
We have several loop-scoped global variables now. Some are Python objects, but llist_node is a plain C structure.
Let's make a super-base C Extension class where we can put all these objects (both python and plain C) and inherit BaseEventLoop from it.
I personally feel that we will have more loop-scoped things like llist_node in the future; now is a good time to settle a place for them.

[kumaraditya303]

Yes, the only current task is needed instead of the dict after storing the current task in the loop.
I'm talking about a slightly different thing.
We have several loop-scoped global variables now. Some are Python objects, but llist_node is a plain C structure.
Let's make a super-base C Extension class where we can put all these objects (both python and plain C) and inherit BaseEventLoop from it.
I personally feel that we will have more loop-scoped things like llist_node in the future; now is a good time to settle a place for them.

I see, I have created a new issue #128633 to look more into this. Let's continue the discussion there.