Re: What's the difference between a "coroutine" and a "thread" in Lua?

[Asko Kauppi <askok@...>]

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.