bpo-32296: Implement asyncio.get_event_loop and _get_running_loop in C. #4827
Conversation
| @@ -88,6 +91,134 @@ class _asyncio.Future "FutureObj *" "&Future_Type" | |||
| static PyObject* future_new_iter(PyObject *); | |||
| static inline int future_call_schedule_callbacks(FutureObj *); | |||
|
|
|||
|
|
|||
| static int | |||
| get_running_loop(PyObject **loop) | |||
There was a problem hiding this comment.
Pretty sure you had a reason for this design but I still cannot figure out why not PyObject* get_running_loop().
The function returns a loop, Py_None if loop not found and NULL on error.
Incref/decref of Py_None is instant and relative rare -- we assume the function is called mostly from coroutines.
The signature looks more native to C Python developer -- almost never API call used pointer for storing result but most of them returns PyObject*.
There was a problem hiding this comment.
But this is not a public CPython API. This is an internal helper function, which either sets a pointer to the currently running event loop or not. It returns a status of that operation as an int result. This is a common pattern in C.
There was a problem hiding this comment.
And it's a common pattern for helper functions in CPython code base too.
Yeah, I agree, I want C API too. Let's think about it after 3.7. |
|
But wait. |
asyncio.get_event_loop(), and, subsequently asyncio._get_running_loop() are one of the most frequently executed functions in asyncio. They also can't be sped up by third-party event loops like uvloop. When implemented in C they become 4x faster.
Good idea. Done. |
asyncio.get_event_loop(), and, subsequently asyncio._get_running_loop()
are one of the most frequently executed functions in asyncio. They also
can't be sped up by third-party event loops like uvloop.
When implemented in C they become 4x faster.
https://bugs.python.org/issue32296