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

[Kevin Ruland]

Bertram Ludaescher wrote:
>>>> 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? 
>
>   
I suppose you're thinking of something like firefox's download manager.  
That would be very nice but would be a new feature which needs to be 
approved soon in order to be included in the feature freeze at the end 
of Feb.  Bring it up next week and we can discuss its utility, in this 
context, as well as feasibility.

> 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)
>
>   
Right.  Since initialize cannot be interrupted, I should think that it 
would be even shorter than a few seconds.  In the case of these actors, 
right now they just verify that the data load is complete.  If it isn't 
complete then they raise the IllegalActionException which can be 
interpreted as either "not ready yet" (in this case), or "improperly 
configured" (as should be the case for other actors).  My understanding 
of the initialize() method is it is supposed to verify proper configuration.

This brings me to another idea, instead of having initialize() in these 
data actors block for completion of download, it would be completely 
possible for them to block in prefire or fire.  That is, they don't wait 
until they are actually called upon to do something useful.  I will play 
with this and see if stop then does what I hope it to.

> 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!? 
>
>   
It would be possible, in this case, for stop to terminate the d/l, then 
play/pause, would simply restart the d/l.
> 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!? 
>
>   

The data load actually happens before play.  The user has no control 
over its beginning or end - this is perhaps a bad thing.