bpo-32296: Implement asyncio.get_event_loop and _get_running_loop in C.#4827
bpo-32296: Implement asyncio.get_event_loop and _get_running_loop in C.#48271st1 merged 2 commits intopython:masterfrom
Conversation
asvetlov
left a comment
There was a problem hiding this comment.
Regarding to third-party loops and other extensions: it would be nice to have C API for asyncio. Not sure how to do it: asyncio is shared module, Python C API is not linked with _asyncio.
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