Multitasking Proposal

[Tim Michals]

Yes, it is a cross between several ideas that are being posted here.  

[King, Mike]

To summarize, I've listed the proposed solutions to the problem.  I realize my descriptions are overly summarized.  Please revise if you like.  Second of all, I'm not sure everyone agrees on what the problem is.  Is there a subset of the problem space that we can agree on?


Official Lua on a RTOS
pros: using the official Lua codebase
cons: complexity and larger memory requirement

Collaborative multitasking using Coroutines
pros: using the standard library provided by Lua
cons: slower interrupt handling

Debug library hooking
pros: faster interrupt handling (sort of)
cons: slower execution speed

Preemptive Coroutines with Locking
short description: injecting a yield into instruction stream
pros: faster interrupt handling
cons: locks and complexity involved

Preemptive Coroutines with Message Passing
short description: injecting a yield into instruction stream
pros: faster interrupt handling
cons: the message passing infrastructure would use RAM

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential or proprietary to K&L Microwave, Inc. Any unauthorized review, use, disclosure or distribution is prohibited.
If this communication has been transmitted from a U.S. location it may also contain data subject to the International Traffic in Arms Regulations or U.S. Export Administration Regulations and, if so, cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, without the prior approval of the U.S. Department of State or appropriate export licensing authority. If you have received this communication in error, please notify the sender by reply e-mail and delete or destroy all copies of this e-mail message and/or any file attachment(s).

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Fabien]

Two additional remarks, drawn from personal experience:

• In practice, you need some locking mechanisms even in collaborative multithreading, although mmuch less frequently. At least some form of mutex.
• The kind of work done under interruption and within demanding realtime constraints is usually simple and not portable. As a result, the advantage of Lua over C in such contexts isn't as huge as usually.

Also, there's a serious issue with the Java-like multithreading model, as opposed to the Unix-like multi-process model. With threads (shared memory), you'll eventually leak memory as your application grows more complex, and the only way to fix this is by rebooting the whole VM.

In a well designed Unix application, there are lots of short-lived processes with separate data (save some carefully delimited IPC). Many of those processes won't even bother freeing allocated memory: everything is reclaimed when the process is killed, at the end of its ideally short life. This forgotten but robust way of managing memory is finally rediscovered, e.g. in Google Chrome's architecture. Building an application this way is a strong incentive to choose RTOS preemptive processes, *if* the underlying OS is powerful enough and you're willing to use processes the proper way. However, such OSes will more typically run the regular Lua VM than eLua.

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev