[kepler-dev] Can "stop" interrupt "initialize()"
ludaesch at ucdavis.edu
Sun Jan 29 18:52:39 PST 2006
Your suggestion about changing things in the "guts" of Ptolemy scares
me a bit. Moreover, I think it's probably not needed.
We had recently an exchange (on kepler-dev) about different workflow
stages or phases, among them something that could be called "data
staging". I think it's time we recognize that we need to state the
requirements data staging, then come up with a design that extend
Ptolemy/Kepler without further overloading the native Ptolemy
In particular, I think the "VCR buttons" for "Play", "Pause", and
"Stop" need to be augmented with other buttons for data staging (if
necessary), static type checking (when desired) etc. Doing things
under the (Ptolemy) hood doesn't seem like a good idea.
Is there a requirements or design document for the features you've
described and that we need? If not, we should probably put this on the
agenda of the upcoming Kepler meeting..
What do you think?
>>> On Sun, 29 Jan 2006 17:51:11 -0600
>>> Kevin Ruland <kruland at ku.edu> wrote:
KR> In Kepler we have some actors which download large volume of data in the
KR> background. They do this without any control from the director. In
KR> essence this is done when the actor is instantiated and should complete
KR> prior to the user running the workflow (ie, before initialize() is called).
KR> I was looking at the problem we're having with ptexecute where these
KR> workflows bomb because ptexecute does not know that it needs to wait
KR> until the data is loaded before executing the workflow.
KR> I was thinking of two different alternatives here. The first is to have
KR> initialize() verify that the data download is complete and raise an
KR> IllegalActionException if it is not complete. This provides feedback to
KR> a real user when they press "go" too soon, but does not fix the problem
KR> we have with ptexecute because it will just bomb when initialize() fails.
KR> The other alternative is to have initialize() block until the data is
KR> downloaded. This solves the ptexecute problem. The problem now is with
KR> the UI. After a real user presses "go", the "stop" button does not
KR> appear to do anything. I believe that stop does not attempt to
KR> interrupt actors stuck in initialize().
KR> I think the best solution overall, is to have the stop button actually
KR> interrupt the workflow thread. The InterruptedException could be
KR> trapped and converted into an IllegalActionException. Unfortunately,
KR> such a change would very likely be deep in the guts of Ptolemy, and
KR> could potentially have other unintended consequences. What do you think?
KR> Posted to the ptolemy-hackers mailing list. Please send administrative
KR> mail for this list to: ptolemy-hackers-request at ptolemy.eecs.berkeley.edu
More information about the Kepler-dev