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. -- Javier
Attachment:
signature.asc
Description: This is a digitally signed message part.