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

[Luis Ibanez]

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

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

Hannu Helminen wrote:

> In my suggested patch, I only store an exception flag in the worker 
> thread to ThreadInfoStruct, which is then read by the main thread.
>
> Better option would be to store the actual exception object. But there 
> are some difficulties in this approach:
>
> 1) It is not possible to determine which exception occurred in run 
> time. Even though ITK only throws itk::ExceptionObject, user code or 
> the operating system can throw std::exception or even something else. 
> Catching these objects by correct type and then re-throwing them will 
> be quite tedious.
>
> 2) Copying the exception object usually requires allocating new memory 
> from the heap. If the original exception was caused by a low memory 
> condition, this may cause another exception, which will not be handled.
>
> If the intent is to propagate the reason of the exception up, probably 
> best option would be to catch for both std::exception (which is also a 
> superclass of itk::ExceptionObject) and the ellipsis construct 
> "catch(...)". The reason code from std::exception::what() function is 
> then stored to a (perhaps pre-allocated) buffer, which is then 
> re-thrown in the main thread as an itk::ExceptionObject.
>
>
> There should be no need to modify the ThreadedGenerateData() 
> functions, since the exception handling is in a separate function 
> within the itk::MultiThreader.
>
> However, as a consequence of this change, it *could* be possible to 
> clean up the interface of the multitheader callback function. 
> Currently it is
>
> ITK_THREAD_RETURN_TYPE CallbackFunction(void *argument)
>
> where the return type depends on the threading model used, and the 
> argument has to be cast with reinterpret_cast. In interest of code 
> clarity, both the cast and the return value could be moved to inside 
> itk::MultiTheader, and the signature could be e.g.
>
> void CallbackFunction(MultiThreader::ThreadInfoStruct *argument)
>
> This would also allow for the possibility of compiling in support for 
> two or more threading models simultaneously. Currently this is not 
> possible, since the choice of ITK_THREAD_RETURN_TYPE is made at 
> compile time.
>
>
> I am not familiar enough with the ITK's event model to know how to use 
> it to interrupt a lengthy calculation. In general the problem with 
> such voluntary methods of aborting an algorithm is that abortion has 
> to be anticipated in each algorithm separately. Taking a concrete 
> example, how should I interrupt the code in 
> itkStatisticsImageFilter::ThreadedGenerateData()? As far as I can see, 
> the only way to interrupt this code before iteration is complete is to 
> throw an exception from within the progress reporter.
>
> Hannu
>
>
> PS. The subject line should of course read "exception safety", not 
> "thread safety" ;-) But that was probably obvious.
>
>
>
>> From: "Miller, James V (Research)" <millerjv@crd.ge.com>
>> To: "'Hannu Helminen'" <Hannu.Helminen.0001@dosetek.varian.com>,
>>         insight-users@public.kitware.com
>> Subject: RE: [Insight-users] Thread safety of itkMultiThreader
>> Date: Wed, 2 Oct 2002 12:48:26 -0400
>> X-Mailer: Internet Mail Service (5.5.2653.19)
>>
>> I think your model of the "correct behavior" sounds good.
>> I haven't looked though your changes enough to determine how the
>> worker threads communicate the exception to the main thread. Is
>> it merely the return status indicating an exception occurred or
>> is the actual exception object passed to the main thread?
>>
>> Would we need to change the ThreadedGenerateData() methods
>> in each filter to catch the exceptions or is that catch
>> encapsulated in the Multithreader code?
>>
>> A note on your use of exceptions.  We decided internally to
>> restrict our use of exceptions to events that were truely
>> exceptional (ran out of memory, disk error, etc.) and to use
>> Observers/Events to capture operations like a user aborting
>> a filter. Would ITK's events have worked for you here?
>
>
> Hannu Helminen
> Varian Medical Systems Finland Oy
> This is a temporary mail account that may get deleted after spambots 
> harvest the email address.
>
> _______________________________________________
> Insight-users mailing list
> Insight-users@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-users
>