Re: Lua and preemptive scheduling for coroutines

[Leo Romanoff <romixlev@...>]

>>  - Explicit yields are easy to forget at certain places

> And easy to add when missed. :) Unless you have no global state you're
> going to end up adding some mechanism to your system to stop a
> coroutine being interrupted half way through an operation and hence
> leaving the global state in a bad way.

I understand what you mean. I also do not say I want to use preemption most of the time or as the only mechanism.
I'm thinking about it more as a fallback solution for protection from stalls and eventually for time-slicing.
In reality, I most likely would use a combination of cooperative multitasking and preemptive for some specific subsets of my coroutines or for specific situations.

>>  - Code may loop forever, especially a 3rd party untrusted code, which you 
> may want to run by loading scripts
> You cannot stop this from Lua (without removing _all_ C functions from
> the sandbox), you need to use threading or processes at the OS level
> to limit access to resources.
> 
>>  - 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.
>> 
> Repeating myself but unless you don't have any C functions in your
> sandbox it's impossible to make guarantees like this using a debug
> hook. Any C function can potentially stall the entire thread
> indefinitely. Harder to do accidentally but if it's going to bring
> down your application then you'll need to address it outside of Lua in
> either case.

But let's say I don't have C functions in my call stack. Or if I have them, they are controlled by me (i.e. not a third party) and behave properly. They never stall for too long.
And if hook happens in the middle of such a C function, I'm OK with waiting until it is done and returned back to Lua function/coroutine.

So, let's say, I don't need to solve the most generic scenario that you described.

And let's not drift too far away from the original question:
- With the limitations described above (i.e. we do not try to solve the most generic case), is it technically possible to implement preemptive approach like I asked for using Lua and may be a few C libs, but avoiding writing new C code for each new coroutines-based Lua application that would like to use such a preemptive support feature?

>>  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.
>> 
> At millions of actors I'm guessing using a debug hook is going to be
> really bad for your performance characteristics. I'm not suggesting
> coroutines are a bad fit, just that pre-empting them defeats half of
> the benefits in order to save a few keystrokes.


I agree that debug hooks are probably not the best and most performing solution. But it is the only one I've found so far.
As I said, I'm a newbie to Lua, so may be I overlook better methods available. If so, please teach me how to do it better.

-Leo