lua-users home
lua-l archive

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



We might already be in the Future you wish for. Only, Lua 5.1 is plenty enough as it is. :)

	http://kotisivu.dnainternet.net/askok/bin/lanes/index.html

At the end of that page there's comparison to other solutions out there:

	http://kotisivu.dnainternet.net/askok/bin/lanes/index.html#comparisons

- there is no application level locking needed, at all

* true multiprocessing, handy where there is more than one CPU (as there so often is these days);

check.

no need scrupulously to avoid blocking I/O in your code (much more complex than it sounds, especially when making queries into third- party back ends which access disk, such as SQL databases);

hmm, there's many ways to solve this. One that comes to mind is having a "worker thread" for dealing with such (non-multithreading) library, and then conversing with that thread via message passing.

* no instant collapse in performance when you slip up on the previous point and inadvertently perform some blocking operation.

I don't really get this one. What do you mean?

-asko


Duck kirjoitti 14.8.2007 kello 1:24:


Can you please list such tasks, where built-in
pre-emptive parallelism would have been useful.

I think it's a matter of choice and of widening the appeal of Lua a little.

I find it pretty hard to write correct code using low-level pthreads-style multitasking because of the need to take (great) care to handle all the synchronisation by hand. But many recently- blooded programmers are used to it, and expect it, even though they too might not actually be terribly good at it :-)

OTOH, I find an API like LuaTask (q.v.), which is implemented atop pthreads-style multitasking, a very natural way to write programs with multiple parallel tasks of execution. And LuaTask would, I suspect, be fairly easy to implement on top of an officially- included and more generic multitasking API such as LuaThreads (see some recent earlier, errr, email thread about this).

I guess the appeals of a core-but-optional LuaThreads or LuaTask include:

* true multiprocessing, handy where there is more than one CPU (as there so often is these days);

* no need scrupulously to avoid blocking I/O in your code (much more complex than it sounds, especially when making queries into third-party back ends which access disk, such as SQL databases);

* no instant collapse in performance when you slip up on the previous point and inadvertently perform some blocking operation.

Perhaps even some evil scheme for allowing multi-tasking between
multiple Lua states with such a scheme could be even more useful?

This is sort-of what LuaTask does. It's kind of like old-school share-nothing parallelism (anyone remember the Transputer :-) implemented inside Lua using OS-level threads, and with a built-in, simple and inexpensive IPC/synchronisation mechanism using message passing.

The only problem with LuaTask is that (sorry, Daniel :-) the current release version has an unremediated critical bug, and that there are some question marks over its production-readiness from at least one theoretical analysis, and from one practical report, recently published on this list. But the core idea is very neat. Multithreaded multitasking without all those !$@%^% mutexes:-)

I have also, a couple of years back, used LuaThreads and found it very handy in numerous cases. For example, with a little bit of high-level glue to handle the !$@#$ mutexes it was easy to write a sort-of inetd in Lua, which allowed me to turn simple Lua scripts into concurrent network servers without hassling about shielding all my I/O in non-blocking wrappers, portably on Linux and Windows. And for writing simple "backgrounder" utilities (such as "print this whilst I go on in the foreground with other stuff") it's certainly handy, if not strictly necessary, to have true preemptive multiprocessing. All this with very little additional run-time code (which only needs to be loaded if you want or need it).

My $2.