Re: Lua and preemptive scheduling for coroutines

[petah_lua <lua@...>]

>I'm thinking about it more as a fallback solution for protection from stalls and eventually for time-slicing.

Maybe you could have a watchdog in a 2nd thread to monitor spawned coroutines and terminate them on resource quota threshold... assuming you have major restrictions on the code running in coroutines so they're fail-able, i.e. terminating them is fine, they'll be serviced again later [1]. That means they'd have to be "const" wrt to your program core logic.

Debugging resource hogs is a LOT easier than race conditions.

>>>  - Code may loop forever, especially a 3rd party untrusted code, which you 
>> may want to run by loading scripts

If you don't trust code running in coroutines you have a worst-case scenario (voiding my 1st suggestion).

>is it technically possible to implement preemptive approach like I asked for using Lua

I think this isn't really Lua-specific; it's a much broader architectural problem. Your description so far is way too vague (for me at least) to suggest practical solutions. 

You determined that all-out multithreading is too resource-intensive while coroutines aren't, but they're orthogonal concepts.

With preemption you have to deal with mutexes, atomic operations, messaging, etc., and total PITA race conditions. Coroutines avoid these because they're only concurrent in appearance and code path switches are carefully orchestrated among all parties. Trying to breed them will most likely result in a frail mutant. I doubt Lua will magically solve this for you, even with heavy VM-hacking, but I'd love to be proven wrong.

cheers,

-- p

[1] a friend had written an Apple ][gs file loader while a flicker-free 3D logo spun, which was theoretically impossible. The trick: when a disk read failed due to the raster-synced 3D render+blit, the sector would just be reloaded. The loader was slightly slower but you'd be too focused on the "no way in hell" spinning logo to notice :)