[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: another try at multithreading
- From: "Javier Guerra" <javier@...>
- Date: Thu, 19 Jun 2008 07:32:34 -0500
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