lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Monday 31 December 2007, Duck wrote:
> Whenever multithreading in Lua comes up, three possibilities are usually
> mentioned:
> 1. LuaThread, which is now out-of-date, requires a (very
> slightly) non-standard Lua core, and requires the programmer to take care
> of synchronisation issues.
> 2. LuaTask, recently bumped up to 1.6.4, and pretty fully documented, yet
> dismissed by some as "dead" or at least "inactive".
> 3. Lua Lanes, which is sometimes described as "active" and promoted as
> the way to go.

i'm at least one who recently 'dimissed' LuaTask and 'promoted' Lua Lanes.  If 
that was what led you write this, let me state in public that:

1) i didn't do any research to back my commentaries
2) i haven't used either one
3) i have my own 'competing' solution (helper threads toolkit)

so please take whatever i say in this topic with a huge chunk of salt :)

that said, why in the first place did i say that? well, maybe it was just a 
personal perception, but when i first came to Lua, i looked around for a 
multitasking solution and found only LuaTask and LuaThread. didn't like 
LuaTask because it relies in message passing, and since i wanted to share 
complex objects, that meant lots of serialisations (which i think are the 
source of most inefficiencies around).  after trying LuaThread for a while, i 
realised that the locking needed by Lua's inner structures destroyed most 
opportunities for real paralelization.

time passed... and then came LuaLanes, which is a rehash of the ideas behind 
LuaTask, therefore i didn't think too well about it.  but then it passed 
through its period of quick growth, with several announcements in this list.  
i didn't review the code, just a bit of the docs, and i saw (or imagined) 
some efforts to handle message passing a little better, with support for some 
higher level objects than just numbers and strings.  that, and not having any 
news from LuaTask (not that i looked for them) tilted my view to favour the 
newcomer instead of the 'original'

and about my own project? it's in deep freeze... or maybe stagnation.  in 
fact, i think (of course (: ) that it would be the best solution for lots of 
situations; but it needs more support libraries to reach there.  even worse, 
ideally we would have to rework most libraries using it to really make it 
_the_ solution.


Attachment: signature.asc
Description: This is a digitally signed message part.