Re: Lua Lanes -- a new (?) concept for parallel Lua

["Jérôme VUARAND" <jerome.vuarand@...>]

2007/2/8, Asko Kauppi <askok@dnainternet.net>:
> It may be a bit early to throw this in the air (implementation at 0%)
> but I'd want to know if there's any glitches in the design. Throwing
> stones requested, in other words... ;)
>
> Lua Lanes
>
>    f= lane( ...chunk-of-lua-code... )
>
>    a= f( ...args... )   -- starts chunk in a new thread
>    b= f( ...other-args... )     -- another thread
>    ...
>    print( a[1] + b[1] ) -- first use of returned values

> From my point of view this does not bring much to existing solutions
to the problem. It's just a bridge between lazy evaluation and a
threading library. Lazy eval examples are in the list archive, and
several threading library already exist. IMHO bridging the two
wouldn't require more than a few tens of pure Lua lines. Simple (far
from bullet-proof and untested) example :

lazy = function(f, ...)
   local args = {...}
   return setmetatable({}, {__index=function(self)
       local results = { f(unpack(args)) }
       -- Make sure future access won't recompute results
       getmetatable(self).__index = function(self) return unpack(results) end
       return unpack(results)
   end})
end

lane = function(f, ...)
   -- Assume 'thread' creates and starts a thread with f as thread code
   local t = thread(f, ...)
   -- Assume t:join wait for thread completion and returns f results
   return lazy(function() return t:join() end)
end

f = function(...) chunk.of.lua.code() end

a = lane(f, unpack(args.a))
b = lane(f, unpack(args.b))
...
print( a[1] + b[1] )

I hope the stone wasn't too hard :-)
Besides, it's 2am here, I may have missed your point. My most sincere
apologies if that's the case.