Re: communicating sequential processes

[Asko Kauppi <askok@...>]

I'm a fan of LuaProc's approach, as well.

The basic difference to Lanes that I can recall was not having a 1:1  
relationship to OS threads. That makes LuaProc way more scalable.

It does not matter if one only wants 10+ threads (Lua states) but it  
starts to matter in 100's and 1000's.

Someone could merge the two efforts, s.a. teaching Lanes to use  
coroutines so that the N:M mapping becomes possible. Unfortunately, I  
won't be having much time in the future on Lua any more.

-asko


Mark Hamburg kirjoitti 25.4.2009 kello 20:04:

> The communication channel is limited in what it can pass, but you  
> might want to read the paper on LuaProc:
>
> Exploring Lua for Concurrent Programming
>
> LuaForge release at:
>
> LuaForge: luaproc: Project Info
>
> That said, it's fairly straightforward to implement this sort of  
> support using Lua coroutines. The chief issue that comes into play  
> in an implementation is that if you want to allow other uses of  
> coroutines beyond yielding back to the scheduler, you need to patch  
> the implementation of yield and resume so that they recognize when a  
> yield needs to work its way back to the scheduler and when they just  
> represent a localized coroutine interaction. I don't know whether  
> there are any publicly available sources that demonstrate that. The  
> basic idea is to extend yield by passing a target as the first item  
> and have resume look at the results and continue yielding if it  
> wasn't meant to receive the value (and then pass the resumption from  
> that yield back down).
>
> Mark