Re: luaproc

[Matthew Wild <mwild1@...>]

On Thu, Feb 19, 2009 at 7:58 AM, Asko Kauppi <askok@dnainternet.net> wrote:
>
> luaproc really seems interesting.
>

Agreed. Finally I have something to say to people who say I should be
writing my project in erlang :)

> The merger of coroutines (yield) and actual parallel threading is smooth.
> Maybe we can get a new threading model in Lua 5.2 (or 6.0) that will merge
> them even further?
>
> Mapping Lua states M:N with OS threads is the right way to go. I shall adopt
> that to Lanes, as well.
>

That's good to know. The only reason I'm hesitating about Lanes at the
moment is that it is restricted to one machine. Transparently
communicating with "processes" running on a remote machine would be
great, but I'm not sure this is a direction Lanes is headed in (and I
quite understand if it isn't).

> What I see as downsides of luaproc is mainly the restriction of message
> types (number, string, boolean). This can be overcome by other addon modules
> that would, for example, implement Linda shared data storage s.a. what Lanes
> has. It need not be part of luaproc itself, though.
>

And this a reason I couldn't (yet) use luaproc. It would be great to
see a solution such as you describe, with as low an overhead as
possible on transfers of other types (primarily tables).

> I do hope luaproc (or a derivative) eventually becomes an integral part of
> Lua, itself. Meaning it would be a package s.a. 'coroutine' currently is,
> and accompany Lua in the source tgz.
>

I suppose it wouldn't, at least as-is. ANSI C doesn't have threads :(

That said, perhaps it could simply disable multiple workers when
compiled on an unsupported platform, and work just as coroutines do
today.

Things are getting interesting, great projects, both. :)

Matthew.