Fwd: RE: [Insight-users] Thread safety of itkMultiThreader : Aborting filter execution

[Luis Ibanez]

Jim,

Yes, that's a good idea,
otherwise it will add another check to the inner loops and probably slow
things down more than necesary.


Looking into the UnaryFunctorFilter for example, it looks like we may
even absorb the ImageIterator   into the ProgressReporter.  In that way
the loop


   while( !it.IsAtEnd()   && !this->GetAbortGenerateData() )
     {
     // do something
    ++it;
    reporter.CompletedPixel();
    }


could rather look like

      do
       {
       // do something
       }  while( reporter.NextPixel() );


"NextPixel() in the reporter will contain:

        ++it;
        CompletedPixel();

and will check for the GenerateAbortData only every NUpdate pixels,
the return will be boolean for NextPixel() could be

       !it.IsAtEnd()

or just "false" when the test for GenerateAbortData() returns true;


The price for this is that the ProgressReporter will have to be
templated over the IteratorType and its constructor will require
an Iterator as input.  The constructor will look ok because the
NumberOfPixels can now be obtained internally from the Iterator.


Also, recently an "IteratorReporter" was also added for those filters
that perform iterations and cannot know in advance how long it will
take for them to run.  A similar approach could be followed in this
IteratorReporter.


Another option is to integrate the role of the ProgressReporter
into the Iterators. That could in fact be cleaner. The iterators will
then have to receive the "this" pointer of the "ProcessObject"
on which they are running.



I guess that this is something to be done after next week meeting....



    Luis


=================================================

Miller, James V (Research) wrote:

>Luis,
>
>Could this check be put into the progress reporter?
>
>The progress reporter would return the value of m_AbortGenerateData.
>
>
>
>>-----Original Message-----
>>From: Luis Ibanez [mailto:luis.ibanez@kitware.com]
>>Sent: Thursday, October 03, 2002 10:30 AM
>>To: Hannu Helminen
>>Cc: insight-users@public.kitware.com; Miller, James V (Research)
>>Subject: Re: Fwd: RE: [Insight-users] Thread safety of 
>>itkMultiThreader
>>: Aborting filter execution
>>
>>
>>Hi Hannu,
>>
>>About the mechanism for stopping filters during execution:
>>
>>The itkProcessObject has a boolean member variable:
>>
>>          m_AbortGenerateData
>>
>>That can be Set/Get with
>>
>>         SetAbortGeneratData( );
>>         GetAbortGeneratData( );
>>
>>Since all ITK filters derive from the ProcessObject, users can
>>stop filter from a GUI by invoking
>>
>>        myFilter->SetAbortGenerateData( true );
>>
>>or
>>       
>>        myFilter->AbortGenerateDataOn();
>>
>>
>>The problem is that filters are not checking for this condition
>>in their inner loops.....
>>
>>Right now, this condition is only tested in the 
>>itkStreamingImageFilter.
>>
>>So, it seems that we will have to visit all the filters and add this
>>checking in order to allow users to abort a process....
>>
>>Once the filters are aborted they will send an StopEvent() that
>>a GUI can use to keep the user informed.
>>
>>In this way you can exit a filter nicely... without throwing 
>>exceptions.
>>
>>Thanks for pointing this out
>>
>>
>>    Luis
>>
>>===================================
>>
>>