On Monday, February 17, 2003, at 04:50 AM, Andreas Raab wrote:
what am I missing?
Simplicity, efficiency and robustness. And a guy named Heisenberg ;) Try it. It's the simplest solution since all of the critical invariants are ensured primitively. Just think about the scheduler itself - if it were running at a higher priority you'd need to tell it when to release the next process. But what if 'yer aborted, terminated, killed? How could the scheduler decide if there's already a script running? etc. You'd have to communicate too many things explicitly that I know for given implictly by the very fact some process is currently running.
And I clearly don't know enough yet to really come to a conclusion. I like Heisenberg. The inability to precisely measure position and velocity or time and energy hopefully have something to offer us in the world of asynchronous messaging. It would provide a little leeway in exactly when and where an event occurred and was handled. It's probably an emergent property of deadline based scheduling.
I am not sure why you couldn't attach a state machine to the process so that it would do the right thing when a scheduler Process asked it to reschedule itself. There looks to be quite a bit of state in ScriptProcess already. Since all scripts are at the same priority, you are allowed to do this, right? If they could have different priorities, then you could be interrupted. What is the low-priority scheduler Process? Is it the ticker?
I am currently more concerned with the lost scripts that I am experiencing. I opened a Process Browser and sure enough, there were all my Scripts waiting on Semaphores. I must have opened up a hole somewhere by a) submitting multiple scripts (in a loop) and/or b) not signaling a semaphore (or calling some method which does this under the covers).
I should have the next consolidated package this week sometime. As we discussed, I will include the Scripting changesets, so that it can be loaded separately from Croquet.
cheers, rob