RE: Lua and preemptive scheduling for coroutines

[Thijs Schreijer <thijs@...>]

> -----Original Message-----
> From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On
> Behalf Of Leo Romanoff
> Sent: vrijdag 29 maart 2013 7:44
> To: Lua mailing list
> Subject: Re: Lua and preemptive scheduling for coroutines
> 
> > I wonder what exactly you're hoping to gain from making the yields
> implicit?
> 
> - Explicit yields are easy to forget at certain places
In my experience, this is a minor problem. But that's only after trying, before it, my initial thoughts were the same.

> - Code may loop forever, especially a 3rd party untrusted code, which you
> may want to run by loading scripts
Execute that in a sandbox or using Lanes or both. Can mitigate it, dunno if you can prevent it.

> - 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.
The way you want to use it, you'll probably have to roll your own coroutine scheduler anyway, so this is just a spec for writing that

> - 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.
> 
With this amount, using the debug library doesn't sound like a good idea from a performance perspective.

Thijs