[Insight-developers] Managing Abort in Filters
Miller, James V (Research)
millerjv@crd.ge.com
Tue, 8 Apr 2003 15:51:53 -0400
The AbortGenerateData flag is not propagated down the pipeline.
Paul pointed this out a couple of years ago. There currently is
no facility for informing downstream filters that something aborted.
So propagating the exception up to the application is probably the
best thing to do.
Unfortunately, this probably leaves the pipeline in an inconsistent
state. Without the exception, the abort logic sets the progress
of an aborted filter to 1.0 before continuing on down the pipeline.
So if the exception hits the application, the progress of the aborted
filter will still be at whatever position it was at. Worse than that,
the downstream filters may have their progress 1.0 from the last time
they executed. Progress is set to zero just before GenerateData() is
called and set to 1.0 just after GenerateData() is called.
Second, when the pipeline is executing, a flag is set on the current
filter to keep track of the fact that it is updating. This keeps a
pipeline from getting in a recursive update. When a filter aborts,
this flag is not reset.
There is a method called ResetPipeline() that can be called on a filter
that will reset this flag so that the pipeline can be reused.
> -----Original Message-----
> From: Luis Ibanez [mailto:luis.ibanez@kitware.com]
> Sent: Tuesday, April 08, 2003 11:37 AM
> To: Miller, James V (Research)
> Cc: Insight Developers List
> Subject: Re: [Insight-developers] Managing Abort in Filters
>
>
>
> Hi Jim,
>
> My mistake, I misspelled the name of the Exception
> in the email. The actual name in the code is
> "ProcessAborted", since this is done at the level
> of the ProcessObject.
>
> We could certainly add a hierarchy of more detailed
> exceptions under the "Abort" category...
>
> The filters modifies so far are catching the exception,
> cleaning memory when necessay and then rethrowing the
> exception with the correct LINE and FILE data.
>
> The reason for using exception as a mechanism of
> communication between the progressReporter and the
> Filter is that we don't want to keep asking for
> (is AbortGenerateData() == true ?), at each pixel
> processed. Placing this question in the Progress
> Reporter schedules the question every (TotalPixels/100)
> pixels.
>
> Alternative options include:
>
>
> 1) make the Iterator itself know about the filter
> and inside the iterator ++ check for the Abort Flag
>
>
> 2) let the progress Reporter hold a pointer to the
> iterator and le it move the iterator to the End
> position with the aim of ending the while loop.
> This options is ok for filters with a single while
> loop, but when there are severeal nested while loops,
> it will start looking like good old COBOL code.
>
>
> -----------------
>
>
> The question at this point is:
>
> if we have filters
>
> A -----> B
>
> and we cancel "A" while it is in its GenerateData()
> method...
>
>
> 1) what will "B" do ?
>
> 2) Is the AbortGenerateData flag automatically propagated
> to all the filters downstream ?
>
> 3) How is indicated that the output of all pending filters
> is now invalid ?
>
>
> In the meantime, the current implementation is letting
> the ProcessAborted exception propagate up to the level
> of the applicatoin GUI, where, after all, the abort
> action originated when the user clicked in a "Cancel"
> button.
>
>
>
> Luis
>
>
>
> ------------------------------------
> Miller, James V (Research) wrote:
> > Is "ProgressAborted" the right name for the exception?
> > I don't think of it as the "progress" being aborted as
> > much as the filter being aborted. 'Course the only thing
> > I can come up with right now is "AbortGenerateDataException".
> > I think we want something more specific than just "AbortException".
> > Looking at our other exceptions, some end in the word
> > "Exception" and some end in the word "Error". (Rambling)
> >
> > This approach is using exceptions as a means to
> > communicate between the ProgressReporter object and
> > the filter. We are basically trying to hide duplicate
> > code in the ProgressReporter class. To date, however,
> > I think we have tried to restrict the use of exceptions
> > to "errors" as opposed to "state". But I guess, this is
> > kind of in the gray area. I am not worried about the
> > overhead of the exception since it is only thrown when
> > the user select "abort".
> >
> > The bottom line is that if a filter uses a ProgressReporter
> > it had better catch this exception. We never want this
> > exception to propagate up to the application.
> >
> >
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: Luis Ibanez [mailto:luis.ibanez@kitware.com]
> >>Sent: Tuesday, April 08, 2003 10:36 AM
> >>To: Insight Developers List
> >>Subject: [Insight-developers] Managing Abort in Filters
> >>
> >>
> >>Hi,
> >>
> >>The following approach for managing Abort calls
> >>has been added (tentatively) to filters:
> >>
> >>1) The ProgressReporter tests for the
> >> AbortGenerateData flag after calling
> >> ProgressUpdate(). That gives the user
> >> a chance to click in an "Abort/Cancel"
> >> button when the GUI is refreshed after
> >> the progress update.
> >>
> >>2) If the progress reporter finds the AbortGenerateData
> >> flag ON, it throws a (newly added to the toolkit)
> >> "ProgessAborted" exception.
> >>
> >>3) Filters should catch this "ProgressAborted" exception
> >> outside the outer loop of their GenerateData() and
> >> ThreadedGenerateData() methods.
> >>
> >>
> >>
> >>This logic has been added to the following
> >>filter classes:
> >>
> >>
> >> - UnaryFunctorImageFilter
> >> - BinaryFunctorImageFilter
> >> - TernaryFunctorImageFilter
> >> - MedianImageFilter
> >>
> >>The first three cover most of the pixel-wise filters.
> >>
> >>
> >>
> >> Luis
> >>
> >>
> >>
> >>_______________________________________________
> >>Insight-developers mailing list
> >>Insight-developers@public.kitware.com
> >>http://public.kitware.com/mailman/listinfo/insight-developers
> >>
> >
> >
>
>
>