Has any thought been givento multithreading the scripting in Celestia? This would get rid of the frame halts and the arbitrary run period aborts - frame rates would be much smoother, and a lot of the current limitations on scripting would be lifted.<Br><br>
What critical issues would arise? How tightly bound to the Celestia engine itself is the scripting language?
Multithreading for LUA
-
Topic authorthekryptonian
- Posts: 5
- Joined: 31.10.2004
- With us: 20 years
- Location: Simi Valley
Re: Multithreading for LUA
For many applications you need to keep control over the work done without interruption by frame-rendering.thekryptonian wrote:Has any thought been givento multithreading the scripting in Celestia? This would get rid of the frame halts and the arbitrary run period aborts - frame rates would be much smoother, and a lot of the current limitations on scripting would be lifted.
If you get "frame halts" (I guess you mean noticeable delays during rendering) or script termination due to exceeding the maximum timeslice, then the script is wrong. It should contain more wait() commands. For long-running loops you can check how much time has passed since the last wait, and call wait once every 0.1s (i.e. don't call wait every time, this would ruin the performance of the loop).
BTW, what limitations do you think would be lifted by this?
What critical issues would arise? How tightly bound to the Celestia engine itself is the scripting language?
Lua itself doesn't allow simulating multithreading, and real multithreading (if it is actually possible in Lua - I doubt it) isn't even used by Celestia itself, so multithreading isn't an option for pure technical reasons at this time. Any interruption to the execution of the script has to be initiated by the script itself... even the termination when exceeding the maximum timeslice is a hack.
Harald
HankR wrote:Is it possible to run two Lua scripts simultaneously (via cooperative multitasking)?
I didn't try, but this should be possible using coroutines. And because the wait-command is actually a wrapper around the command to return from a coroutine you don't even have to modify the script-source. Of course you have to watch out for name clashes with global variables and functions, and many CELX-commands don't work well with more than one script at the same time (e.g. printing text on screen etc.)
Harald
-
Topic authorthekryptonian
- Posts: 5
- Joined: 31.10.2004
- With us: 20 years
- Location: Simi Valley
Re: Multithreading for LUA
If you get "frame halts" (I guess you mean noticeable delays during rendering) or script termination due to exceeding the maximum timeslice, then the script is wrong. It should contain more wait() commands. For long-running loops you can check how much time has passed since the last wait, and call wait once every 0.1s (i.e. don't call wait every time, this would ruin the performance of the loop).
BTW, what limitations do you think would be lifted by this?
Well, that one, for starters. It would be a superior ability to be able to write scripts without having to periodically massage the interleave between frame rendering and script execution. This limitation seems to be an unnecessary encumberment, making it much more difficult to script for Celestia that it could otherwise be. It probably also contributes siginficantly to the time it takes to develop a complex script.
I would guess that since Celestia was not designed to allow event-driven interaction between user and universe, that this sort of thing really isn't much of an issue if you're not thinking of trying to make a space flight simulator out of it or something.
Re: Multithreading for LUA
Any other limitations?thekryptonian wrote:Well, that one, for starters.(forced to call wait)... what limitations do you think would be lifted by this?
As I already wrote this is primarily a technical problem - AFAIK you can't do it, at least not with Lua (v5) and without introducing OS-level multithreading to Celestia, which isn't easy when keeping cross-platform compatibility.It would be a superior ability to be able to write scripts without having to periodically massage the interleave between frame rendering and script execution. This limitation seems to be an unnecessary encumberment, making it much more difficult to script for Celestia that it could otherwise be. It probably also contributes siginficantly to the time it takes to develop a complex script.
But in many cases it's even easier to work with - you don't have to worry about synchronization issues. And to be honest I rarely find adding a "wait" somewhere a problem, at least since Celestia doesn't block when I forget it.
I would guess that since Celestia was not designed to allow event-driven interaction between user and universe, that this sort of thing really isn't much of an issue if you're not thinking of trying to make a space flight simulator out of it or something.
It's apparently consensus among the developers that Celestia should not become a space flight simulator
Harald