[Insight-developers] interrupting filter execution

[Miller, James V (GE, Research)]

Paul,

So what does your final version of the ReportProgress() look like?

Did you essentially just move the check for GetAbortGenerateData() to the
beginning of the method?  

Also, it is only the DiscreteGaussian filter where you could not properly
catch the exceptions?  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?

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

-----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: Thursday, July 20, 2006 11:31 AM
To: insight-developers at itk.org
Subject: Re: [Insight-developers] interrupting filter execution


Paul Koshevoy wrote:
> Paul Koshevoy wrote:
>
>   
>> void
>> ProgressAccumulator
>> ::ReportProgress(Object *, const EventObject &event)
>> {
>>   static SimpleFastMutexLock mutex;
>>   {
>>     MutexLockHolder<SimpleFastMutexLock> mutexHolder(mutex);
>>     
>
> Now that I think of it, this mutex is probably unnecessary. I'll try
> again tomorrow without it.
>   
I just tried it -- it works fine without the mutex. The question now is 
what should be done with this change -- will it be integrated into the
ITK or will I have to patch ITK every time?

Thank you,
    Paul.

_______________________________________________
Insight-developers mailing list
Insight-developers at itk.org
http://www.itk.org/mailman/listinfo/insight-developers