[IGSTK-Developers] Discussion about Exceptions & Events in the VXL mailing list
David Gobbi
dgobbi at atamai.com
Wed Oct 19 17:46:49 EDT 2005
Hi Luis,
I read through the collection of emails, and I think
that it is tangential to what we are doing in IGSTK.
These people are discussing something that is, from my
view, a misuse of exceptions. They are not discussion
the use of exceptions in any way that we would ever
consider using them in IGSTK (at least I hope!). My
comments on when exceptions could potentially be
used in IGSTK are on the wiki.
My perspective is that the right tool should always be
applied to the situation at hand. Some situations call for
events, some call for exceptions, and sometimes even a
good old if/else is A-OK, as long it doesn't circumvent
the state machine.
- David
Luis Ibanez wrote:
> As a continuation of our discussions today,
> it may be of interest to take a look at the
> following mailing thread in the VXL list.
>
> It was originated by a question from Karthik
> regarding the possibility of reporting iteration
> events from VNL optimizers.
>
> Among the proposed solutions, Exceptions are
> mentioned and some of the pros and cons are
> discussed in this thread.
>
>
> Luis
>
>
> ----
>
>
> ------------------------------------------------------------------------
>
> Subject:
> Vxl-users digest, Vol 1 #561 - 9 msgs
> From:
> vxl-users-request at lists.sourceforge.net
> Date:
> Tue, 18 Oct 2005 16:26:54 -0700
> To:
> vxl-users at lists.sourceforge.net
>
> To:
> vxl-users at lists.sourceforge.net
>
>
>Send Vxl-users mailing list submissions to
> vxl-users at lists.sourceforge.net
>
>To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/vxl-users
>or, via email, send a message with subject or body 'help' to
> vxl-users-request at lists.sourceforge.net
>
>You can reach the person managing the list at
> vxl-users-admin at lists.sourceforge.net
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Vxl-users digest..."
>
>
>Today's Topics:
>
> 1. Re: Include libraries!! (Amitha Perera)
> 2. VNL Optimizers responding to events (Karthik Krishnan)
> 3. Re: VNL Optimizers responding to events (Ian Scott)
> 4. Re: VNL Optimizers responding to events (Amitha Perera)
> 5. Re: VNL Optimizers responding to events (Ian Scott)
> 6. RE: VNL Optimizers responding to events (Miller, James V (Research))
> 7. Re: VNL Optimizers responding to events (Ian Scott)
> 8. RE: VNL Optimizers responding to events (Andrew Fitzgibbon)
> 9. Re: VNL Optimizers responding to events (Karthik Krishnan)
>
>--__--__--
>
>Message: 1
>Date: Mon, 17 Oct 2005 23:57:00 -0400
>From: Amitha Perera <perera at cs.rpi.edu>
>To: Maria Perez <reduvita2000 at yahoo.com.mx>
>Cc: vxl-users at lists.sourceforge.net
>Subject: Re: [Vxl-users] Include libraries!!
>
>[I'm cc'ing the list again, to make sure this discussion thread is
>archived for future searches, etc.]
>
>
>On Mon 17 Oct 2005, Maria Perez wrote:
>
>
>>Hi:
>> I did
>> make VERBOSE=1
>>
>>and "-lmyPrograms" appears in the link line. Do you
>>have another idea that what's happening?
>>
>>
>
>In your original post, the files were ".c" files, and hence would
>have C bindings, not C++ bindings. Maybe this is the problem. In
>xcv_xfer.cxx, try to include your routines as
>
> extern "C" {
> #include "myPrograms/example.h"
> }
>
>Amitha.
>
>
>--__--__--
>
>Message: 2
>Date: Tue, 18 Oct 2005 11:03:20 -0400
>From: Karthik Krishnan <Karthik.Krishnan at kitware.com>
>To: vxl-users at lists.sourceforge.net
>Subject: [Vxl-users] VNL Optimizers responding to events
>
>Hello,
>
>I am trying to use VNL optimizers in image registration algorithms. This
>mechanism is conveniently provided by ITK. One of my needs is to
>terminate the optimization process prematurely by a user defined event,
>say from a GUI. I was hoping that there would be some mechanism to have
>the optimizers in VNL respond to events. Unfortunately this is not the
>case.
>
>I am sure this is a common problem. I was wondering if this has come up
>before and if VNL provides mechanisms to deal with this. I suppose the
>way VNL deals with it currenltly is set some convergence criteria. But
>it is not always easy to define one a-priori.
>
>Looking at the code for a few optimizers, such as vnl_amoeba, I suppose
>it wouldn't be hard to provide a StopOptimizationNow() method that can
>be accessed via a callback from a GUI.
>Except, I am a puzzled why the "minimize" methods in vnl_amoeba and
>several methods in vnl_amoebaFit are static. Is there a reason for this ?
>
>Thanks
>Regards
>Karthik
>
>
>
>
>--__--__--
>
>Message: 3
>Date: Tue, 18 Oct 2005 16:44:07 +0100
>From: Ian Scott <ian.m.scott at stud.man.ac.uk>
>To: Karthik Krishnan <Karthik.Krishnan at kitware.com>
>Cc: vxl-users at lists.sourceforge.net
>Subject: Re: [Vxl-users] VNL Optimizers responding to events
>
>This seems to me to be a perfect place to use c++ exceptions.
>
>Exceptions would certainly work through vnl_amoeba which is written in
>C++. However, the core of the other optimisers are written in C
>(originally fortran), and sit in v3p/netlib. I think that in some cases
>(e.g. LM optimisation), the C code optimiser gets given the cost
>function as a C-linkage function-ptr. This function-ptr then calls back
>to the C++ vnl_cost_function. I don't know if exceptions would be passed
>through this C code. For other optimisers (e.g. LBGFS) the C++ wrapper
>code vnl_lbfgs calls the c++ cost function itself, and then passes the
>function and gradient values to the netlib code to get the next
>iteration. Exceptions would certainly work well here.
>
>For a similar reason, modifying amoeba and lbfgs to take a call-back
>function would be possible if unpleasant. However, modifying the netlib
>code to take a callback function is something we would be very reluctant
>to do.
>
>A third solution would be to use threads. Put the optimisation in a
>separate thread (or process) and then kill the thread when required by
>the main program thread.
>
>It is possibly that the optimiser code is not very exception or
>thread-safe. However this is not a reason to use callbacks, as these
>would likely be harder to clean up after than exceptions.
>
>Ian.
>
>
>Karthik Krishnan wrote:
>
>
>>Hello,
>>
>>I am trying to use VNL optimizers in image registration algorithms. This
>>mechanism is conveniently provided by ITK. One of my needs is to
>>terminate the optimization process prematurely by a user defined event,
>>say from a GUI. I was hoping that there would be some mechanism to have
>>the optimizers in VNL respond to events. Unfortunately this is not the
>>case.
>>I am sure this is a common problem. I was wondering if this has come up
>>before and if VNL provides mechanisms to deal with this. I suppose the
>>way VNL deals with it currenltly is set some convergence criteria. But
>>it is not always easy to define one a-priori.
>>
>>Looking at the code for a few optimizers, such as vnl_amoeba, I suppose
>>it wouldn't be hard to provide a StopOptimizationNow() method that can
>>be accessed via a callback from a GUI.
>>Except, I am a puzzled why the "minimize" methods in vnl_amoeba and
>>several methods in vnl_amoebaFit are static. Is there a reason for this ?
>>
>>Thanks
>>Regards
>>Karthik
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by:
>>Power Architecture Resource Center: Free content, downloads, discussions,
>>and more. http://solutions.newsforge.com/ibmarch.tmpl
>>_______________________________________________
>>Vxl-users mailing list
>>Vxl-users at lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/vxl-users
>>
>>
>
>
>
>--__--__--
>
>Message: 4
>Date: Tue, 18 Oct 2005 12:52:23 -0400
>From: Amitha Perera <perera at cs.rpi.edu>
>To: Ian Scott <ian.m.scott at stud.man.ac.uk>
>Cc: Karthik Krishnan <Karthik.Krishnan at kitware.com>,
> vxl-users at lists.sourceforge.net
>Subject: Re: [Vxl-users] VNL Optimizers responding to events
>
>I think the issue is more complex than that. What Karthik suggests
>requires multiple threads in vnl. For the optimizer to stop its
>iterations, it needs to be told to do so *from its thread*. This
>could be by toggling a variable that that is monitored at the
>beginning of each iteration, or by calling a function that will
>return "continue" or "stop". Somewhere in this will be a variable
>that will be read from the optimizer thread but will be written to
>from the GUI thread. This requires mutexes to do it right.
>
>Not using mutexes in this case would probably work most of the time,
>but I think if we are going to add something like this, it should be
>done correctly.
>
>I guess a solution could be to use an indicator function---a function
>with signature "bool stopnow()"---which is passed in as a parameter
>to the optimizer. The thread-safety issues would then by the user's
>responsibility, because he'll have to implement this function. Of
>course, as Ian wrote, this would only really work when the vnl
>routine is more than a simple wrapper around netlib.
>
>Ian also suggested exceptions. In this case the function could throw
>an exception instead of returning a bool. However, I think a lot of
>vnl (and vxl) is unfortunately not exception-safe. Using exceptions is
>quite likely to leak memory, etc.
>
>Also keep in mind that many routines in netlib (and therefore in vnl)
>are not threadsafe.
>
>All in all, I think it's doable, but would require some effort and
>thinking through some of the issues raised when mixing exceptions and
>threads with code not written with either in mind.
>
>Amitha.
>
>
>--__--__--
>
>Message: 5
>Date: Tue, 18 Oct 2005 17:56:59 +0100
>From: Ian Scott <ian.m.scott at stud.man.ac.uk>
>To: Amitha Perera <perera at cs.rpi.edu>
>Cc: Ian Scott <ian.m.scott at student.manchester.ac.uk>,
> Karthik Krishnan <Karthik.Krishnan at kitware.com>,
> vxl-users at lists.sourceforge.net
>Subject: Re: [Vxl-users] VNL Optimizers responding to events
>
>Amitha Perera wrote:
>
>
>
>>Ian also suggested exceptions. In this case the function could throw
>>an exception instead of returning a bool. However, I think a lot of
>>vnl (and vxl) is unfortunately not exception-safe. Using exceptions is
>>quite likely to leak memory, etc.
>>
>>
>
>Sounds like an excellent opportunity to fix some exception saftey issues
>in vnl - not that I'm volunteering :-)
>
>
>Ian.
>
>
>--__--__--
>
>Message: 6
>Subject: RE: [Vxl-users] VNL Optimizers responding to events
>Date: Tue, 18 Oct 2005 13:09:07 -0400
>From: "Miller, James V \(Research\)" <millerjv at crd.ge.com>
>To: "Amitha Perera" <perera at cs.rpi.edu>,
> "Ian Scott" <ian.m.scott at stud.man.ac.uk>
>Cc: "Karthik Krishnan" <Karthik.Krishnan at kitware.com>,
> <vxl-users at lists.sourceforge.net>
>
>A callback solution should work for the use case at hand. If the =
>optimizers
>would stick the head up from the sand periodically, say once per =
>iteration=20
>or once per k iterations, they could call a user supplied callback. The
>user supplied callback can then peek into the event queue and determine
>whether the UI element to stop the optimization has been selected. If
>selected, the callback sets an abort flag that the optimizer checks when =
>
>it returns from the callback.
>
>We have used this methodology in VTK and ITK for 10 years. No threading
>needed. No exceptions handling needed (exceptions should really be =
>reserved
>for truly exceptional events and not for state management).
>
>The difficulty is doing this is that many of the netlib routines never
>stick there up from the sand. So there is no opportunity to call the
>user supplied callback. A general event mechanism would not only have to
>be used through vnl but also down into netlib.
>
>Jim
>
>
>-----Original Message-----
>From: vxl-users-admin at lists.sourceforge.net
>[mailto:vxl-users-admin at lists.sourceforge.net]On Behalf Of Amitha Perera
>Sent: Tuesday, October 18, 2005 12:52 PM
>To: Ian Scott
>Cc: Karthik Krishnan; vxl-users at lists.sourceforge.net
>Subject: Re: [Vxl-users] VNL Optimizers responding to events
>
>
>I think the issue is more complex than that. What Karthik suggests
>requires multiple threads in vnl. For the optimizer to stop its
>iterations, it needs to be told to do so *from its thread*. This
>could be by toggling a variable that that is monitored at the
>beginning of each iteration, or by calling a function that will
>return "continue" or "stop". Somewhere in this will be a variable
>that will be read from the optimizer thread but will be written to
>from the GUI thread. This requires mutexes to do it right.
>
>Not using mutexes in this case would probably work most of the time,
>but I think if we are going to add something like this, it should be
>done correctly.
>
>I guess a solution could be to use an indicator function---a function
>with signature "bool stopnow()"---which is passed in as a parameter
>to the optimizer. The thread-safety issues would then by the user's
>responsibility, because he'll have to implement this function. Of
>course, as Ian wrote, this would only really work when the vnl
>routine is more than a simple wrapper around netlib.
>
>Ian also suggested exceptions. In this case the function could throw
>an exception instead of returning a bool. However, I think a lot of
>vnl (and vxl) is unfortunately not exception-safe. Using exceptions is
>quite likely to leak memory, etc.
>
>Also keep in mind that many routines in netlib (and therefore in vnl)
>are not threadsafe.
>
>All in all, I think it's doable, but would require some effort and
>thinking through some of the issues raised when mixing exceptions and
>threads with code not written with either in mind.
>
>Amitha.
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Power Architecture Resource Center: Free content, downloads, =
>discussions,
>and more. http://solutions.newsforge.com/ibmarch.tmpl
>_______________________________________________
>Vxl-users mailing list
>Vxl-users at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/vxl-users
>
>
>--__--__--
>
>Message: 7
>Date: Tue, 18 Oct 2005 18:49:58 +0100
>From: Ian Scott <ian.m.scott at stud.man.ac.uk>
>To: "Miller, James V (Research)" <millerjv at crd.ge.com>
>Cc: Amitha Perera <perera at cs.rpi.edu>,
> Ian Scott <ian.m.scott at student.manchester.ac.uk>,
> Karthik Krishnan <Karthik.Krishnan at kitware.com>,
> vxl-users at lists.sourceforge.net
>Subject: Re: [Vxl-users] VNL Optimizers responding to events
>
>It turns out that exceptions are passed through the netlib code (on
>MSVC7.1 anyway) See my recent modification to
>core/vnl/algo/tests/test_levenberg_marquardt.cxx for a demonstration.
>
>As for exceptions being inappropriate for state control, whilst I agree
>in general, I do think that it depends on the context. Using exceptions
>all the way up to the GUI may be inappropriate, because it isn't
>exceptional behaviour for the GUI. However for the optimiser, it is
>exceptional behaviour. Most people don't need such abort behaviour, so
>it would be inappropriate to complicate the code (even further) to
>handle it.
>
>There should be no significant overheads to using exceptions on modern
>compilers - or at least not compared to handling the alternative
>callback-abort situation properly. As for making the code
>exception-safe, running valgrind over the test I just committed, should
>find all the relevant leaks in vnl_levenberg_marquardt.
>
>I'll admit to being biased in favour of exceptions, because I would like
>to see some attention paid to the exception safety of the code. However,
>I do think they are the simplest solution described so far. (Total
>coding time for the above test - 4 minutes)
>
>Ian.
>
>Miller, James V (Research) wrote:
>
>
>>A callback solution should work for the use case at hand. If the optimizers
>>would stick the head up from the sand periodically, say once per iteration
>>or once per k iterations, they could call a user supplied callback. The
>>user supplied callback can then peek into the event queue and determine
>>whether the UI element to stop the optimization has been selected. If
>>selected, the callback sets an abort flag that the optimizer checks when
>>it returns from the callback.
>>
>>We have used this methodology in VTK and ITK for 10 years. No threading
>>needed. No exceptions handling needed (exceptions should really be reserved
>>for truly exceptional events and not for state management).
>>
>>The difficulty is doing this is that many of the netlib routines never
>>stick there up from the sand. So there is no opportunity to call the
>>user supplied callback. A general event mechanism would not only have to
>>be used through vnl but also down into netlib.
>>
>>Jim
>>
>>
>>-----Original Message-----
>>From: vxl-users-admin at lists.sourceforge.net
>>[mailto:vxl-users-admin at lists.sourceforge.net]On Behalf Of Amitha Perera
>>Sent: Tuesday, October 18, 2005 12:52 PM
>>To: Ian Scott
>>Cc: Karthik Krishnan; vxl-users at lists.sourceforge.net
>>Subject: Re: [Vxl-users] VNL Optimizers responding to events
>>
>>
>>I think the issue is more complex than that. What Karthik suggests
>>requires multiple threads in vnl. For the optimizer to stop its
>>iterations, it needs to be told to do so *from its thread*. This
>>could be by toggling a variable that that is monitored at the
>>beginning of each iteration, or by calling a function that will
>>return "continue" or "stop". Somewhere in this will be a variable
>>that will be read from the optimizer thread but will be written to
>>from the GUI thread. This requires mutexes to do it right.
>>
>>Not using mutexes in this case would probably work most of the time,
>>but I think if we are going to add something like this, it should be
>>done correctly.
>>
>>I guess a solution could be to use an indicator function---a function
>>with signature "bool stopnow()"---which is passed in as a parameter
>>to the optimizer. The thread-safety issues would then by the user's
>>responsibility, because he'll have to implement this function. Of
>>course, as Ian wrote, this would only really work when the vnl
>>routine is more than a simple wrapper around netlib.
>>
>>Ian also suggested exceptions. In this case the function could throw
>>an exception instead of returning a bool. However, I think a lot of
>>vnl (and vxl) is unfortunately not exception-safe. Using exceptions is
>>quite likely to leak memory, etc.
>>
>>Also keep in mind that many routines in netlib (and therefore in vnl)
>>are not threadsafe.
>>
>>All in all, I think it's doable, but would require some effort and
>>thinking through some of the issues raised when mixing exceptions and
>>threads with code not written with either in mind.
>>
>>Amitha.
>>
>>
>
>
>
>--__--__--
>
>Message: 8
>Subject: RE: [Vxl-users] VNL Optimizers responding to events
>Date: Tue, 18 Oct 2005 18:54:31 +0100
>From: "Andrew Fitzgibbon" <awf at microsoft.com>
>To: "Miller, James V \(Research\)" <millerjv at crd.ge.com>,
> "Amitha Perera" <perera at cs.rpi.edu>,
> "Ian Scott" <ian.m.scott at stud.man.ac.uk>
>Cc: "Karthik Krishnan" <Karthik.Krishnan at kitware.com>,
> <vxl-users at lists.sourceforge.net>
>
>
>Agree with Jim. A "should I stop now?" callback is fine. I thought
>there was one in lmdif, and can't check now, but take a look at the
>return value of the function-evaluation callback and see if it examines
>that.
>
>
>
>--__--__--
>
>Message: 9
>Date: Tue, 18 Oct 2005 19:25:13 -0400
>From: Karthik Krishnan <Karthik.Krishnan at kitware.com>
>To: Amitha Perera <perera at cs.rpi.edu>
>CC: Ian Scott <ian.m.scott at stud.man.ac.uk>, vxl-users at lists.sourceforge.net,
> "Miller, James V (Research)" <millerjv at crd.ge.com>,
> Andrew Fitzgibbon <awf at microsoft.com>
>Subject: Re: [Vxl-users] VNL Optimizers responding to events
>
>
>Amitha Perera wrote:
>
>
>
>>I think the issue is more complex than that. What Karthik suggests
>>requires multiple threads in vnl. For the optimizer to stop its
>>iterations, it needs to be told to do so *from its thread*. This
>>could be by toggling a variable that that is monitored at the
>>beginning of each iteration, or by calling a function that will
>>return "continue" or "stop". Somewhere in this will be a variable
>>that will be read from the optimizer thread but will be written to
>>
>>
>>from the GUI thread. This requires mutexes to do it right.
>
>
>>Not using mutexes in this case would probably work most of the time,
>>but I think if we are going to add something like this, it should be
>>done correctly.
>>
>>
>>
>>
>>
>I agree. ITK has a few classes to handle mutexes, thanks to Jim Miller.
>My concern was mutexes would be awfully slow, but they aren't that slow
>after all.
>
>Here is a minimal example. And the mutex is the equivalent of a dozen
>multiplications.
>
>#include "itkSimpleFastMutexLock.h"
>#include "itkRealTimeClock.h"
>static unsigned long int Counter = 0;
>static itk::SimpleFastMutexLock mutex;
>int main()
>{
> const unsigned int N = 400000L;
> { itk::RealTimeClock::Pointer clock = itk::RealTimeClock::New();
> const double T1 = clock->GetTimestamp();
> for(unsigned long i=0; i < N; i++)
> {
> mutex.Lock(); Counter++; mutex.Unlock();
> }
> const double TT = clock->GetTimestamp() -T1;
> std::cout << "Time = " << TT / N << std::endl;
> }{ itk::RealTimeClock::Pointer clock = itk::RealTimeClock::New();;
> const double T1 = clock->GetTimestamp();
> for(unsigned long i=0; i < N; i++)
> {
> Counter++;
> float i=5.33547; i*=4.52632; i*=4.52632; i*=4.52342;
>i*=4.52232;
> i*=4.52632; i*=4.52632; i*=4.52342; i*=4.52232; i*=4.52632;
>i*=4.52632;
> }
> const double TT = clock->GetTimestamp() -T1;
> std::cout << "Time = " << TT / N << std::endl;
> }
> return EXIT_SUCCESS;
>}
>
>
>
>
>>I guess a solution could be to use an indicator function---a function
>>with signature "bool stopnow()"---which is passed in as a parameter
>>to the optimizer. The thread-safety issues would then by the user's
>>responsibility, because he'll have to implement this function.
>>
>>
>>
>Why is it the user's responsibility ? Can it not be entirely implemented
>in the optimizer class ?
>
>bool SomeOptimizer::stopnow()
>{
> m_Mutex.Lock(); m_Stopnow=true; m_Mutex.Unlock();
>}
>
>void SomeOptimizer::Optimizer()
>{
> // iterationloop
> {
> m_Mutex.Lock(); if( m_Stopnow) { m_Mutex.Unlock(); break; }
> }
>}
>
>
>
>>Of
>>course, as Ian wrote, this would only really work when the vnl
>>routine is more than a simple wrapper around netlib.
>>
>>
>>
>>
>
>
>
>>Ian also suggested exceptions. In this case the function could throw
>>an exception instead of returning a bool. However, I think a lot of
>>vnl (and vxl) is unfortunately not exception-safe. Using exceptions is
>>quite likely to leak memory, etc.
>>
>>Also keep in mind that many routines in netlib (and therefore in vnl)
>>are not threadsafe.
>>
>>All in all, I think it's doable, but would require some effort and
>>thinking through some of the issues raised when mixing exceptions and
>>threads with code not written with either in mind.
>>
>>
>>
>>
>>
>I don't like the idea of catching exceptions for this purpose either. As
>Jim suggested, a Command-Observer pattern that allows the optimizers to
>call a callback function after every iteration is useful, not just to
>stop optimization but also do some progress reporting and allow other
>kinds of "probing". Now this is already implemented for several
>optimizers in ITK. ITK has optimizer classes that are mere wrappers
>around the VNL ones. ITK uses a class called
>SingleValuedVnlCostFunctionAdaptor that derives from vnl_cost_function
>and overloads the "f()" and the gradf() methods to additionally invoke
>iteration events(). The vnl optimizers are supplied with this class as
>a cost function and since they derive from vnl_cost_function vnl is
>happy. However the problem at hand is a little harder than just throwing
>events, so the GUI can observe them. It is being able to Stop the
>optimization. "Aborting" and "Stopping" the optimization is not the
>same. (the latter returns the computed paramters at that point).
>
>I had tried to abort by throwing an exception from the CostFunction
>class, whose function evaluation method would be invoked during every
>iteration event. This exception is caught by the external application.
>However, the actual optimizer code had things like
>
>minimize( x, .. )
>{
> { // Iteration loop.....
> ....
> f();
> ....
> }
> x = x/10;
>}
>
>As you can see, the "abort" process never calls the final x = x/10 prior
>to aborting.
>So hacks like this don't really work.
>
>There not only needs to be a way for the optimizers to throw events, but
>also for the event to respond with a stop message, for instance .....
>the cost function adator telling the vnl optimizer that "hey when I went
>to evaluate the cost function, I also found out that I need to stop and
>break from the iteration loop".
>
>Thanks for all the responses. I'm really grateful.
>
>Regards
>karthik
>
>
>
>>Amitha.
>>
>>
>>
>>
>PS: vpl_mutex works only for pthreads.. The patch is already there in ITK:
>http://www.itk.org/cgi-bin/viewcvs.cgi/Code/Common/itkSimpleFastMutexLock.cxx?rev=1.3&root=Insight&view=markup
>http://www.itk.org/cgi-bin/viewcvs.cgi/Code/Common/itkSimpleFastMutexLock.h?rev=1.5&root=Insight&view=markup
>
>
>
>
>--__--__--
>
>_______________________________________________
>Vxl-users mailing list
>Vxl-users at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/vxl-users
>
>
>End of Vxl-users Digest
>
>
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>IGSTK-Developers mailing list
>IGSTK-Developers at public.kitware.com
>http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>
>
More information about the IGSTK-Developers
mailing list