Open belm0 opened 3 years ago
Just use an event.
I see.
It's a little unfortunate as far as garbage generation. And I notice that Trio doesn't use slots for Event or ParkingLot, so that's two unslotted class instances for every set().
Even the slimmest possible implementation on asyncio would still instantiate Futures. It might be possible to implement something like a ParkingLot
on asyncio but I haven't invested any time on that yet.
how about:
This will at least make the Trio case efficient, and anyway I think it's good to have an explicit wait queue API rather than require users to be aware of the event idiom.
The asyncio implementation would involve Futures rather than Event, since Event on asyncio is already built around Futures anyway.
Having this API would mean a common Event
implementation based on this rather than the current one where __new__()
instantiates a backend specific subclass.
And I notice that Trio doesn't use slots for Event or ParkingLot, so that's two unslotted class instances for every set().
trio.Event
received some attention and we were able to reduce the number of objects in the implementation by about half.
and here's a PR to make ParkingLot slotted: https://github.com/python-trio/trio/pull/1971
and here's a PR to make ParkingLot slotted: python-trio/trio#1971
This is good change and I overlooked it in my PR. But to clarify: trio.Event() is no longer implemented with ParkingLot.
It may be possible to implement universal task rescheduling. We'll just copy trio's API and use Futures to implement it on asyncio. The question is, if we ever add Twisted support, will this complicate matters?
I'm pondering an anyio implementation of trio-util's AsyncValue, however it's built on Trio ParkingLot.
Is there an asyncio equivalent that could be incorporated into anyio?