[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua Lanes...alive or dead?
- From: Javier Guerra Giraldez <javier@...>
- Date: Tue, 1 Jan 2008 19:18:34 -0500
On Monday 31 December 2007, Duck wrote:
> Whenever multithreading in Lua comes up, three possibilities are usually
> 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
Description: This is a digitally signed message part.