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

[Kevin Ruland]

Bertram,

Things like static type checking may be optional (to the workflow) in 
the sense that one could still execute a workflow without having done 
the static type checking step or perhaps the workflow could be executed 
if static type checking fails (user override?).  In this sense, data 
loading is different because it is necessary to have successfully 
completed data loading prior to execution.

Also, if some actor somewhere does do something extremely time consuming 
in it's initialize method, there is currently no pleasant way to 
interrupt it.  The user can click on the stop button, and it does appear 
to have some effect -- that is, it's indentation changes when pressed -- 
however, it does not interrupt the processing.  This behavior could be 
considered a but itself.  Either the stop button needs to be disabled 
until it can do something useful, or it should stop the workflow 
regardless of its execution state.

I have been given no requirements for the data loading process - other 
than to see if we can make ptexecute work correctly.

Kevin

Bertram Ludaescher wrote:
> 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
>
>