[kepler-dev] Can "stop" interrupt "initialize()"

[Bertram Ludaescher]

Kevin:

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
capabilities.

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?

cheers

Bertram




>>> On Sun, 29 Jan 2006 17:51:11 -0600
>>> Kevin Ruland <kruland at ku.edu> wrote: 
KR> 
KR> Hi.
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> 
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> 
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> 
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> 
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> 
KR> Kevin
KR> 
KR> ----------------------------------------------------------------------------
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