Screens Environment is a multi-platform component based middleware research project designed to connect technologies together and provide better user experiences for the future of computing http://sourceforge.net/projects/screensos/
Thursday, April 14, 2005
Multi-tasking design
As you all know, Screens wants to bring semi pre-emptive multi-tasking to the PalmOS platform. Why Semi? Because its cooperative internally but it switches not on a single yield function but can yield on any Screens API call. So as long as the developer does not do an endless loop without calling an API call, the system will continue running.
So how will I do it? I have researched this subject for a long time and this is my theory:
I use setjmp() at the start position (like just after the module gets called via its PilotMain function) and store it somewhere. The code then runs as normal. When I want to stop the current module thread to switch to another, I save the end position (still using setjmp) and its stack (from the start position to the end position) and then use longjmp() to jump to the start position. This then of course exits the module returing to the scheduler. When I want to restore the modules execution, I run the module again and it saves its new start position but then copies the stack back and jumps to the end position and continues execution from there.
Why theory? Because this all works apart from the restore operation which might have unexpected results. So that is what I am going to test. If it works, I will have multi-tasking in Screens so you wont have to code in a single-tasking environment anymore. While there are limitations in my design such as no globals (but thats because modules cannot have globals, instead use the object storage) and only local variables are stored (and the required registers stored by setjmp) so you cannot use anything outside that world. But nothing that normal developers use anyway (dont tell me about signals... most apps dont touch them).
I am going to spend the next month to try and see if it is possible. Where will I store the stack? Not in an object but rather in feature memory. Why not in an object? Well... in the end it is stored in an object but the actual switching code cannot make any Screens API calls because the stack does not always continue after a SysAppLaunch call, so I cannot be sure that I am saving the right stack. The design I have just told you should work on any PalmOS version including Cobalt.
Wish me luck! Because if this works... Screens will have a very compelling reason to code for it.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment