> I wonder what exactly you're hoping to gain from making the yields implicit?
- Explicit yields are easy to forget at certain places
- Code may loop forever, especially a 3rd party untrusted code, which you may want to run by loading scripts
- If you want to implement something like multi-tenancy, where coroutines belong to different tenants and each tenant has a right for running a certain tenant-specific amount of time (e.g. tenant A can run at most 40% of overal time, and tenants B and C - only 30% each). With ability to interrupt coroutines implicitly it becomes much easier.
- My previous experience with Java, where only the thread itself may finish itself, shows that it is not always good to rely on the
thread/coroutine to obey to the rules, when it comes to giving control to other threads/coroutines. If all of your code follows a strict discipline it works. But once you start using third-party libs or forget yielding at a few places, you get into problems.
> It just means that now you have to deal with the synchronisation problems that stem from your code being potentially interrupted at any point while you don't
> pick up the real parallelism from OS pre-emptive threading primitives.
As I mentioned, I have something like millions of actors in mind (e.g. one per player or on per session or one per social network user). You cannot map all of them to OS threading primitives anyway. Therefore, you need to re-invent one ;-) And actors do not need real
parallelism most of the time. They are really similar to coroutines in this regard.
