 |
lua-l archive |
|
|
||
|
On Jul 27, 2015 12:43 PM, "phlnc8" <phlnc8@gmail.com> wrote:
>
> On Sat, Jul 25, 2015 at 5:40 AM, Mason Bogue <scythe+lua@ortsz.com> wrote:
> > http://www.inf.puc-rio.br/~roberto/docs/ry08-05.pdf
> >
> > This library -- which seems to show that Lua can handle concurrent
> > programming quite well -- doesn't appear to be maintained. That's
> > unfortunate, because I don't know if the other solutions available
> > replicate the advantages of luaproc, viz. performance and simplicity.
>
> +1
>
> It looks like the thesis has been completed, the paper has been
> published, and that's it.
>
> I also think that luaproc approach is _really_ promising. I would be
> interested in having Roberto's position on this. Does he consider it
> a one-shot student work? Or, at the other end of the spectrum, are
> there minions in the Lua secret labs working on a future "parallel
> programming" addition to Lua 5.4? :-)
>
I really hope a future Lua version will provide (or allow a module to provide in an unmodified Lua) true multithreading. With multi-core processors being so common now, not being able to make use of them is rather limiting. Even Python, the "batteries, charger and solar cells included" language, seems to have missed this boat - it provides "threading", but only one thread can actually run at a time (global interpreter state is locked while executing) and it doesn't sound like it'd be easy to fix without breaking other things.
I recall Lua provides some macros lua_lock and lua_unlock that an implementation can override (by default they do nothing) to allow thread-safe access. Maybe future versions could include e.g. LUA_USE_PTHREAD, LUA_USE_WINAPI_THREAD, etc, enabled by default on appropriate platforms, which would implement a basic mutex? Or would that add too much overhead to code that isn't using threads? Anyway it sounds like those macros would do much the same as Python's global lock, i.e. no actual parallel execution. So maybe not even worth doing?
The thread libraries I've used run a separate Lua state in each thread and provide some type of communication channel between them. This is a nice simple model, but maybe not the most efficient. In particular, while it's usually possible to pass most types of Lua objects between threads, tables can only be recursively copied, functions have to be dumped and recompiled (and can't have upvalues), and userdata can't safely be passed around unless it's designed to be referenced by multiple Lua states.
Even just a module that uses separate Lua states for each thread but can work around some of those limitations (which I suspect would require a modified Lua), e.g. copying tables/functions/userdata directly between states without the need for slow dumping/reloading or recursive copying, would be great. If it were possible for the same object to be referenced by multiple states, even shared tables and functions with upvalues should be possible - mutexes could be attached to them automatically when they're made available to another thread, so you avoid the problem that some coffee-inspired languages have, wasting time and memory with locking and unlocking every object even when only one thread uses them.
The holy grail of course would be true parallel execution, using multiple CPU cores, within one Lua state. It's just unfortunate that threading is one of those annoying things that's extremely difficult to do correctly, but extremely easy to do in a way that seems to work but contains a subtle, critical flaw that only manifests in production at 16:53 on a Friday, just once, and then can't be reproduced until everyone has dismissed it as cosmic ray induced error and given up looking for the bug.