Andreas, I should have sent out a quick note thanking you, 2 days ago. So..thanks for the explaination of the Script interface, and the discussion around how it works. Things got very busy at work so I didn't have an opportunity to look deeper until last night.
I should have the two linked this weekend. I am currently writing an EventualScriptMessageSend, that holds and activates a resolver, when the computation is completed. This is the return continuation.
I am curious about your use the ivar #myQueue in the ScriptProcess. I really like that your ScriptProcess will compute a value, and that that value is the 'result' of the process. That's a very standard view of computations. Isn't it a functional view? A better approach for supporting eventual sending may be to have a subclass of ScriptProcess which holds the continuation to the invocation site.
From: Andreas Raab [mailto:andreas.raab@gmx.de]
[TeaProcessScheduler]
I am not sure, but I am thinking that this interruptability breaks the event-loop model.
Yes, most likely so. This is a (continuous) time-driven framework not a (discrete) event-driven one.
It still must execute activations in a sequential manner, so I wonder if it wouldn't be possible to provide 'uninterruptibility', or whatever is needed to ensure an event-loop, yet still have 'real-time' scheduling.
No system-level changes, yet. :)
cheers, rob