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

Bertram Ludaescher ludaesch at ucdavis.edu
Mon Jan 30 09:26:19 PST 2006


>>> On Mon, 30 Jan 2006 08:49:56 -0800 (PST)
>>> Shawn Bowers <sbowers at ucdavis.edu> wrote: 
SB> 
SB> 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?).
SB> 
SB> Is this really true?  I don't think so in Ptolemy -- i.e., ptolemy throws
SB> exceptions if unexpected types are found.  In general, I'm not sure that
SB> for standard ptolemy/kepler type workflows, it even makes sense to run
SB> them if they are not type safe.

depends on what types we're talking about! 
Data types: yes, those need to be safe (but then again, some types are
only instantiated as the tokens start to flow, right!?)
But semantic types; those are certainly "soft constraints"


SB> 
SB> -shawn
SB> 
SB> 
SB> 
>> 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
>> 



More information about the Kepler-dev mailing list