Matthias Urlichs
Matthias Urlichs
asyncio's `call_soon` just appends the resulting handle to asyncio's `_ready` list. That's reasonably cheap. `trio_asyncio`, however, uses a `trio.Queue`, which is a lot more expensive. I should probably switch to...
Part of the problem obviously isn't the queue, but the dance you need to get there. * replace KI protection with a no-op: 42 µsec * replace `cancel_shielded_checkpoint` with a...
… though we should probably move this somewhere else …
Umm, why do you try to open a loop from within `trio_asyncio.run()`? Anyway, you're right that this is confusing. I'm fixing that part of the documentation.
@miracle2k Is the current version better? ;-) @njsmith On the contrary. The good habit is to establish an asyncio context as soon as possible and keep it running. The bad...
In principle I'm with you, and I agree that this should be the end result. However, another core tenet of Trio is to not require stupid loop= arguments which get...
Nah, *I* was confused, about TaskLocal. I seem to have had a brain fart or whatever. Anyway I'll start with monkeypatching _get_event_loop(), then add a couple of test cases.
Commit f865772 should do the "parallel and/or nesting loops" part. Onwards to improving the documentation …
Third possible solution: create a dummy event loop object with a `__getattr__` that delegates everything to the currently-running TrioEventLoop, or raises an exception if that doesn't exist. That being said...
Mostly, yes. Caching the current event loop is a bad idea these days.