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

[Shawn Bowers]

On Mon, 30 Jan 2006, Kevin Ruland wrote:

>
> 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?).

Is this really true?  I don't think so in Ptolemy -- i.e., ptolemy throws
exceptions if unexpected types are found.  In general, I'm not sure that
for standard ptolemy/kepler type workflows, it even makes sense to run
them if they are not type safe.

-shawn



> 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
> >
> >
>
>
> ----------------------------------------------------------------------------
> Posted to the ptolemy-hackers mailing list.  Please send administrative
> mail for this list to: ptolemy-hackers-request at ptolemy.eecs.berkeley.edu
>