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 Ross Bencina
> Sent: vrijdag 29 maart 2013 11:32
> To: Leo Romanoff; Lua mailing list
> Subject: Re: Lua and preemptive scheduling for coroutines
> 
> 
> On 29/03/2013 8:38 PM, Leo Romanoff wrote:
> >>> -spc (I slowly coming to the idea that pre-emptive multitasking is
> >>> no longer a Good Thing(TM) but I still need to formulate my thoughts
> >>> on  this)
> >
> > In principle, I agree with this. But I'm also not sure that explicit
> > cooperative multi-tasking is such a good thing.
> 
> I would go further and suggest to get rid of:
> 
> (1) any attempt to simulate sequential threads of control (ie
> coroutines) is gilding the lily. better to use a model that makes
> continuations explicit.
> 
> (2) coupling communication with cooperation, as in CSP with blocking
> queue/rendezvous primitives, or having nested event handlers in Erlang
> actions etc.
> 
> Of course the CSP religion is a force to be reckoned with.
> 
> 
> > I think that
> > cooperative implicit multi-tasking (with ability to control at the
> > meta-level or higher-level how cooperation happens, e.g. by means of
> > custom policies or something like this) is more bullet-proof.
> 
> My (completely idiosyncratic) view is that actors with atomic run-to-
> completion actions are a nice model. That way thread switch only happens
> in the scheduler. Actors can be raw handers or state machines (FSMs,
> HFSMs) and communicate (only) via non-blocking queues. Miro Samek has a
> nice practical book on this.
> 
> The main problem in implementing this in Lua would be supporting long
> running computation, (if you need to). Plus you need fully async i/o, but
> that's not so hard to get these days (eg luvit)
> 

Somethings like this example? https://github.com/Tieske/CopasTimer/blob/tasks_as_coroutines/source/copas/timer.lua#L254
See the queue:pop() and queue:pause() calls
I'm rewriting the CopasTimer module to work more coroutine oriented. I think you'll find similar code in the Sierra Wireless scheduler. 

The eventer module of CopasTimer, see https://github.com/Tieske/CopasTimer/blob/tasks_as_coroutines/source/copas/eventer.lua#L199 has some primitives for synchronization. The ev:waitfor() and ev:finish() methods that implicitly yield a coroutine until some else is completed.

> But you want to allow 3rd party code to do stupid stuff and still work.
> A bitter pill for any purist methodology :)

The proposed example of using a debug count hook, could be able to catch that. 
When the hook gets repeatedly called by only one routine, then you could consider it blocking. If it does, then execute some error generating code on that coroutines callstack. That will make the coroutine die because it gets in an error state.

Anyone ever considered to create a separate module for this? could it be implemented generically? Could actually work.

> 
> Ross