[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: luaproc
- From: Matthew Wild <mwild1@...>
- Date: Thu, 19 Feb 2009 13:08:23 +0000
On Thu, Feb 19, 2009 at 7:58 AM, Asko Kauppi <firstname.lastname@example.org> 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
Things are getting interesting, great projects, both. :)