[Insight-developers] interrupting filter execution

[Miller, James V (GE, Research)]

Paul,

Just realized why I was confused by your solution.  I had started working 
on this issue a few months ago but hadn't gotten around to testing it on a 
multiprocessor system. I was doing this just before a release.  I missed the
release date and never got back to it.  I had similar code already in my
copy of the ProgressAccumulator.

However, it turns out that the solution is a bit more complicated that either
of us initially discovered.  I think where you are having long delays on the 
abort is due to the abort operation being done on the outer filter and not
on the inner filter.  So the ProgressAccumulator shouldn't be the one throwing
the ProcessAbort but rather should be propagating the abort flag to the 
appropriate inner filter.

We'll check in the fix on Monday.

Jim

-----Original Message-----
From: insight-developers-bounces+millerjv=crd.ge.com at itk.org
[mailto:insight-developers-bounces+millerjv=crd.ge.com at itk.org]On Behalf
Of Paul Koshevoy
Sent: Friday, July 21, 2006 10:57 AM
To: insight-developers at itk.org
Subject: Re: [Insight-developers] interrupting filter execution


Miller, James V (GE, Research) wrote:
> Paul,
>
> So what does your final version of the ReportProgress() look like?
>
>   
I use ITK 2.4.1, but ProgressAccumulator hasn't changed in 2.8.1, so
here is my patched version:

void
ProgressAccumulator
::ReportProgress(Object *, const EventObject &event)
{
  if (m_MiniPipelineFilter->GetAbortGenerateData())
  {
    m_MiniPipelineFilter->AbortGenerateDataOff();
   
    ProcessAborted e(__FILE__, __LINE__);
    e.SetDescription("ProgressAccumulator detected AbortGenerateData flag");
    throw e;
  }
 
  ProgressEvent  pe;
  IterationEvent ie;
  if( typeid( event ) == typeid( pe ) )
    {
    // Add up the progress from different filters
    m_AccumulatedProgress = m_BaseAccumulatedProgress;

    FilterRecordVector::iterator it;
    for(it = m_FilterRecord.begin();it!=m_FilterRecord.end();++it)
      {
      m_AccumulatedProgress += it->Filter->GetProgress() * it->Weight;
      }

    // Update the progress of the client mini-pipeline filter
    m_MiniPipelineFilter->UpdateProgress(m_AccumulatedProgress);
    }
  else if (typeid( event ) == typeid ( ie ) )
    {
    }
}


> Did you essentially just move the check for GetAbortGenerateData() to the
> beginning of the method?  
>
>   
I added it there, as suggested by Karthik Krishnan.

> Also, it is only the DiscreteGaussian filter where you could not properly
> catch the exceptions? 
DiscreteGaussian is the one I hit most often, because it was relatively
slow compared to other filters, it gave me plenty of time to hit the
stop button. I am not sure why I was not able to catch any of the
multiply-thrown exceptions, but I can catch the exception when it's
thrown only once. I can now report that I have been able to successfully
abort the CastImage  and  ShrinkImage filter. I still can't abort
ImageFileReader -- I don't think it uses a ProgressAccumulator internally.

>  The DiscreteGaussian filter uses a StreamingImageFilter
> internally.  Perhaps that filter is not handling the exceptions properly
> (it is a bit of an odd duck).
>
> If you could try another filter, say something like the MedianImageFilter
> and see of you have the same issues with the original ProgressAccumulator
> code?
>
>   
I'll try.
> The DiscreteGaussian filter also uses a series of NeighborhoodOperatorImageFilters
> which in turn use an itk::ProgressReporter.  The ProgressReporter is set up 
> such that only one thread modifies the progress of a filter (without using mutexes).
> However, all threads check the AbortGenerateData flag and throw a ProcessAborted.
> This is necessary because if only the first thread threw the exception, then the other
> threads for the filter would keep running.  If your app then tried to run the filter
> again immediately, you could have multiple threads trying to modify the same data.
> The Multithreader should catch the exceptions for N-1 of the threads, with only one
> thread rethrowing the ProcessAborted to the calling context.
>
> We may need to build a small executable that mimics what you are doing.  Forces an
> Abort and makes sure the filter shuts down properly.
>
> Ultimately, we'll need to patch ITK.
>
> Jim
>
>   
_______________________________________________
Insight-developers mailing list
Insight-developers at itk.org
http://www.itk.org/mailman/listinfo/insight-developers