lua-users home
lua-l archive

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


On Tue, Jan 13, 2009 at 2:47 PM, Timothy Baldridge <tbaldridge@gmail.com> wrote:
>> I would suggest looking into "ConcurrentLua" which starts from the same
>> basis as you seem to be. Google is your friend here :)
> Actually I looked into it, but unfortunately it doesn't go far enough.

This has been discussed a few dozen times before, you might find the
mailing list archives interesting.

Also, Io has actors builtin to the language, with similar design goals
as Lua in terms of the VM, the programming model (from C), etc.

> The scheduling is still co-operative. So it is possible for one
> process to hog all the processing. Secondly, as far as I can tell the
> VM is still limited to a single CPU which basically limits the
> usefulness of the implementation. On top of all that we still would
> need to modify the Lua syntax to allow for Erlang style message
> filtering.

I don't see any purpose in this. Just use method call syntax, it works
fine. ! makes sense in the context of Erlang's prolog-inspired syntax,
but its just sugar.

> It's a cool hack, but doesn't go far enough to be useful.

Multiple threads can execute inside the same related set of lua states
at the same time, IIRC. You can make it "thread safe" by defining
locking primitives (see LuaThread for an example), but as far as I
know only one CPU will be executing lua opcodes at a time. The threads
and lua's locking works fine when most time is being spent outside of
the VM, in C, blocking on the system or doing CPU intensive tasks.

So, for cuncurrent execution of lua opcodes, you need independent states.

Luckily, lua makes this easy.

Unluckily, Lua can't marshall its data structures between independent
states. If you like Erlang, you don't want global state, but projects
that have tried this before run into difficulty with marshalling
anything other than numbers, strings, and lightuserdata. You might be
able to handle tables, though recursive tables, and objects (aka
tables with metatables) are hard. You can send compiled lua functions,
and I think the debug library can return the source (compiled?) for
some functions, but people have reported problems doing this.

Anyhow, those are some of the issues that foks run into when doing this.

Btw, co-operative works pretty well. One advantage is that you can
send ANY data type (as you can in Erlang, I believe... though possibly
not file handles :-). Also, until not so long ago, Erlang itself was
incapable of using multiple CPUs, demonstrating that the basic model
is still pretty powerful even when single threaded.

Cheers,
Sam