Re: another try at multithreading

["Javier Guerra" <javier@...>]

On Wed, Jun 25, 2008 at 12:07 PM, Augusto Radtke <radtke@radtke.com.br> wrote:
> Interesting indeed, but isn't ANSI C, or even POSIX.  Although

of course.

the best way would be to add some macros at many places, by default
those macros expand to nothing, so there's no impact.  but a few
projects would define them, each choosing their own
portability/efficiency tradeoffs.

> I remember meeting Luiz on IMPA couple years ago to discuss an idea to
> multi-threading in Lua (if you have any interest on that idea, I'm attaching
> the file), that time I didn't have the time to make such a project, now that
> I have I would like to make it, but my major concern for the project, and
> any other kind of project that messes with Lua internals is, can we
> cooperate enough to validate the both trees?

sounds a mostly nice syntax.  i'd prefer adding less keywords and put
most of those into a module

in any case, it allows for two implementations, one with shared memory
and other with separate spaces and copying around.

the first one could be done with current macros that are already in
the code (actualizing LuaThreads?), using a single lock for the whole
space; but that negates almost all concurrency while in the language
core.  of course, it's enough to do blocking I/O without halting the
whole language.

the second one could be implemented on top of LuaLanes / LuaTasks

what i'm trying to do is the next step after LuaThreads: allowing more
concurrency for Lua-heavy code.  either by finer-grain locks, or
lockfree structures

in any case, if you implement your parallellLua on top of LuaThreads,
and meanwhile i get my code to work, it should be easy to add it as an
option to yours.

-- 
Javier