lua-users home
lua-l archive

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


On Thu, Jun 19, 2008 at 12:29 AM, Alex Davies <alex.mania@iinet.net.au> wrote:
> I would be interested to see it. As tables are used throughout Lua for all
> tasks may actually be feasible. The GC's atomic phase would still have to
> block, as it traverses the stack, but other then that lockfree tables may
> well work. Does even len work? I suppose the only real concern would be
> speed (quite a big concern) and possibly table size...

i haven't thought much about GC yet, but i think each thread would get
its own stack, so there's at least two options there: a dedicated GC
thread, that should be careful when traversing stacks, or each thread
could do some GC on its own...

maybe each thread could periodically do the 'mark' step and a
dedicated one would do the 'sweep'? most of these is new to me.  first
concentrate on the data structures

> About locks though, they can be just a single bit if there's no need to nest
> them (there shouldn't be any need in Lua), so it may still be worth trying
> that approach too.

sure, i hope to try a few other ideas.  it's only food for thought at this stage

> And later versions of LuaJIT may take a third approach:
> http://lua-users.org/lists/lua-l/2008-02/msg00051.html
> (Only lock when needed)

if i read this right, it's still a global lock, and locks while
executing Lua, making it undesirable to write CPU heavy code in Lua;
sounds backwards form the goals of such an impressive JIT

-- 
Javier