[Python-Dev] Minimal async event loop and async utilities (Was: PEP 492: async/await in Python; version 4)
p.f.moore at gmail.com
Wed May 6 10:27:16 CEST 2015
On 6 May 2015 at 07:46, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Another problem with the "core" idea is that
> you can't start with an event loop that "just does
> scheduling" and then add on other features such
> as I/O *from the outside*. There has to be some
> point at which everything comes together, which
> means choosing something like select() or
> poll() or I/O completion queues, and build that
> into the heart of your event loop. At that point
> it's no longer something with a simple core.
Looking at asyncio.queues, the only features it needs are:
2. asyncio.futures.Future - creating a standalone Future
locks.Event in turn only needs the other 3 items. And you can ignore
get_event_loop() as it's only used to get the default loop, you can
pass in your own.
And asyncio.futures only uses get_event_loop (and _format_callback)
Futures require the loop to support:
So, to some extent (how far is something I'd need to code up a loop to
confirm) you can build the Futures and synchronisation mechanisms with
an event loop that supports only this "minimal interface".
Essentially, that's my goal - to allow people who want to write (say)
a Windows GUI event loop, or a Windows event loop based of
WaitForXXXObject, or a Tkinter loop, or whatever, to *not* have to
write their own implementation of synchronisation or future objects.
That may mean lifting the asyncio code and putting it into a separate
library, to make the separation between "asyncio-dependent" and
"general async" clearer. Or if asyncio's provisional status doesn't
last long enough to do that, we may end up with an asyncio
implementation and a separate (possibly 3rd party) "general"
More information about the Python-Dev