In #334, we localized the use case of asyncio.get_event_loop() in one function get_or_create_event_loop . Now aiida-core also, only calls on this function and not the fromer.
Having that said, asyncio.get_event_loop() can already be entirely removed from get_or_create_event_loop.
The only use case that's addressing at the moment, is when an event loop is created and set but not yet running. So on the next call it can still return that. This use case seems to be rare or almost none in aiida-core.
There are two suggestion on how to drop it, safely:
- cache the freshly created event loop after setting, and always prioritize returning that one on the next calls (in case that loop is not yet running, but not closed!).
- drop the need of
aiida-core to access such loop. Ideally aiida-core could call only once on asyncio.new_event_loop and pass that loop internally to whoever needs it: transport, engine.utils, etc.
Solution number 2 is cleaner, but it might not be easily doable because also plumpy should follow the same logic in that case.
In #334, we localized the use case of
asyncio.get_event_loop()in one functionget_or_create_event_loop. Nowaiida-corealso, only calls on this function and not the fromer.Having that said,
asyncio.get_event_loop()can already be entirely removed fromget_or_create_event_loop.The only use case that's addressing at the moment, is when an event loop is created and set but not yet running. So on the next call it can still return that. This use case seems to be rare or almost none in
aiida-core.There are two suggestion on how to drop it, safely:
aiida-coreto access such loop. Ideallyaiida-corecould call only once onasyncio.new_event_loopand pass that loop internally to whoever needs it: transport, engine.utils, etc.Solution number 2 is cleaner, but it might not be easily doable because also plumpy should follow the same logic in that case.