Isolate

[patrick-kidger]

Supersedes #20, #21. @aburgm – continuing the conversation from #21. I've squashed your commits and then made some tweaks on top.

I've been noodling on the design here a bit, and I think I've refined it a little further from where we last had it. In particular I'd direct your attention to the devdoc I've added here, which you should treat as if it was the PR description.

WDYT? Right now I'm not feeling 100% sold on this, I'm wondering if it all feels perhaps a bit more advanced than 'tiny'io is really about supporting out-of-the-box.

[aburgm]

Hm, I'm wondering what makes this inherently more complicated than integration with other event loops such as trio?

Note that we definitely need some means of placing things on the main loop (not just the isolated loop), as e.g. we may want an isolated coroutine to consume some input made available by the main loop... a dependency typically expressed as yield some_coroutine.

What if we started with a limited API where this is not possible? (alas I think for my usecase it would be sufficient)

Also to note is that isolate() is only implemented by means of public tinyio APIs, so it doesn't have to live in tinyio proper. Maybe it's enough to add it as an example for people to copy, and then they can choose whatever semantics works best for their usecase (with the downside that then they have to work through the details).

[patrick-kidger]

Hm, I'm wondering what makes this inherently more complicated than integration with other event loops such as trio?

So the main issue is that with different event loops, there is no way in which the same coroutine can appear on both loops. However when both loops are tinyio loops, then this is possible. Or at the very least – it is possible for a user to express that intent. We then need to decide how we should handle that, or how we should detect it and error out.

What if we started with a limited API where this is not possible?

So that's actually pretty much the design of the current implementation, actually. There's now an entirely separate tinyio.copy to handle this detail, and tinyio.isolate doesn't try to do it itself.

Also to note is that isolate() is only implemented by means of public tinyio APIs, so it doesn't have to live in tinyio proper. Maybe it's enough to add it as an example for people to copy, and then they can choose whatever semantics works best for their usecase (with the downside that then they have to work through the details).

Yup, I considered this. On balance I lean towards including it, as I can see that working through the details is likely to lead a user into a footgun. Better to handle it ourselves and carefully wall of the places where mistakes can be made.

(Side note, I think one thing that would complement this well is a way to schedule work on the tinyio loop event even after an error has occurred. It's a bit of a side project, but I'm noodling on some ideas in this direction.)

---

Any commentary on the PR let me know, otherwise I'm happy to merge this :)

[aburgm]

Thanks for the explanations! I don't have major comments, I agree the current approach is the most prudent for now.

[patrick-kidger]

And merged, with a 0.4.0 release! :)