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

[Bertram Ludaescher]

>>> On Mon, 30 Jan 2006 08:41:50 -0600
>>> Kevin Ruland <kruland at ku.edu> wrote: 
KR> 
KR> Bertram,
KR> 
KR> Things like static type checking may be optional (to the workflow) in 
KR> the sense that one could still execute a workflow without having done 
KR> the static type checking step or perhaps the workflow could be executed 
KR> if static type checking fails (user override?).  In this sense, data 
KR> loading is different because it is necessary to have successfully 
KR> completed data loading prior to execution.

I agree that e.g. static type checking is (typically) optional Also it
is different from data loading.  On the other hand, there are
similarities between a long-running job / actor and the data
loading. Whenever things take a very long time, a different "mode of
operation" seems necessary. This what I was arguing for (different
stages or phases) in the light of long-running data loading operations
on start-up. For example, wouldn't it be useful to have the
possibility that the user chooses which dataset is being loaded before
it is actually loaded at startup? 

KR> Also, if some actor somewhere does do something extremely time consuming 
KR> in it's initialize method, there is currently no pleasant way to 
KR> interrupt it.  The user can click on the stop button, and it does appear 

Maybe we should discourage such practice, i.e., having time consuming
initializes. A rule of thumb could be: if it takes longer than a few
seconds, it should be NOT part of the initialization phase, but a
separate phase!? (obviously this needs some more thought)

KR> to have some effect -- that is, it's indentation changes when pressed -- 
KR> however, it does not interrupt the processing.  This behavior could be 
KR> considered a but itself.  Either the stop button needs to be disabled 
KR> until it can do something useful, or it should stop the workflow 
KR> regardless of its execution state.

I guess in Ptolemy, hitting 'stop' implies that the system goes into a
"defined state" so that when hitting 'resume' (currently the same as
'play' ;-) things are consistent. A "hard interrupt" would probably
causes problems with restarting later!? 

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

For the particular workflow at hand, could the dataloading be moved
from the init phase to a later phase (when 'play' has been hit)? Or is
the data loading already happing at 'play' time!? 

Bertram

KR> Kevin
KR> 
KR> 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
>> 
>>