Fixed cleanup not occuring if KI occurs during wait

[patrick-kidger]

Supersedes #16 – credit @aburgm for spotting the underlying error! In this PR I've kept @aburgm's test to validate the fix I've applied.

waits, thunks, loops

@aburgm, you were asking about why we had wait wrapped into a thunk, rather than being called directly. The reason for this is tinyio.to_{asyncio,trio}. The use-case here is when someone has written a tinyio coroutine, but the available event loop is from asyncio/trio. In this case what we need to do is spin up a tinyio loop, but tie its stepping to that of the host event loop – i.e. we want to write an asyncio/trio coroutine which steps the tinyio loop at each await point.

If the tinyio loop finds itself sat waiting, then we need to be able to simultaneously (a) wake the tinyio loop back up once the event triggers, but also (b) allow the host event loop to keep stepping in the mean time. To do this, we move the tinyio event-watching to a thread so that we can do both things simultaneously. In order to perform just the event watching in the thread, we need to wrap that operation in a thunk we can schedule on a thread.

• Credit to trio's 'guest mode' for introducing me to the concept of moving specifically just the event-watching to a thread, and nothing else.
• I've also added some asyncio/trio tests for this integration, which were previously missing (Cancel coroutines when an exception occurs while waiting #16 will fail them.)

other

This PR also swaps out threading.Event for a cross-process compatible choice. Right now this should be invisible to users, but in the future it should enable us to asynchronously launch subprocesses too.

[patrick-kidger]

D:

we started at 200, what is the world coming to.

Maybe it's time to rename to mediumio