Thomas Grainger

@Puemos @d-oliveros @raulromanp There's another npm-published fork at https://www.npmjs.com/package/ngsticky-puemos

this is particularly problematic when a ChildWatcher() instance is holding state there

I think copying the source of asyncio.run and using: ``` asyncio.set_event_loop((policy or asyncio.get_event_loop_policy)().new_event_loop()) ``` Is the way to go

Also I think the `policy` kwarg should be deprecated in favour of a `loop_factory` kwarg, as consumers probably don't want to use run to set the child_watcher

It would make it clear that anyio doesn't touch the child_watcher

So it turns out uvloop needs the uvloop policy child watcher

https://github.com/MagicStack/uvloop/blob/c808a663b297bb2aee745523c277d6fafecebbeb/uvloop/loop.pyx#L2862-L2879

asyncio.runners.Runner now provides a policy free way to select the eventloop implementation. anyio should use this on 3.11 and consider backporting the implementation for other python versions

> https://github.com/MagicStack/uvloop/blob/c808a663b297bb2aee745523c277d6fafecebbeb/uvloop/loop.pyx#L2862-L2879 Turns out this constraint doesn't apply when: * used with the ThreadedChildWatcher on (default on 3.8+) * not using the PidfdChildWatcher (in 3.9 it's broken because it requires...

anyio can backport the `asyncio.Runner` code and provide a `loop_factory` backend option for asyncio