Changeset 9afebe1 in sasview

Timestamp:

Aug 12, 2014 10:00:27 PM (10 years ago)

Author:

butler

Branches:

master, ESS_GUI, ESS_GUI_Docs, ESS_GUI_batch_fitting, ESS_GUI_bumps_abstraction, ESS_GUI_iss1116, ESS_GUI_iss879, ESS_GUI_iss959, ESS_GUI_opencl, ESS_GUI_ordering, ESS_GUI_sync_sascalc, costrafo411, magnetic_scatt, release-4.1.1, release-4.1.2, release-4.2.2, release_4.0.1, ticket-1009, ticket-1094-headless, ticket-1242-2d-resolution, ticket-1243, ticket-1249, ticket885, unittest-saveload

Children:

f4167637

Parents:

eb9fc6d

Message:

patch to Calc1D and Calc2D to deal with problem of threads not handling a stop thread properly causing 2 threads to trample on each other. Thread issues in general may be at the heart of many of our instabilities and should be investigated further.

File:

• src/sans/perspectives/fitting/fitting.py (modified) (2 diffs)

src/sans/perspectives/fitting/fitting.py

@@ -1959 +1959 @@
             if (self.calc_2D is not None) and self.calc_2D.isrunning():
                 self.calc_2D.stop()
+                ## stop just raises a flag to tell the thread to kill
+                ## itself -- see the fix in Calc1D implemented to fix
+                ## an actual problem.  Seems the fix should also go here
+                ## and may be the cause of other noted instabilities
+                ##
+                ##    -PDB August 12, 2014 
+                while self.calc_2D.isrunning():
+                    time.sleep(0.1)
             self.calc_2D = Calc2D(model=model,
                                     data=data,
@@ -1996 +2004 @@
             if (self.calc_1D is not None) and self.calc_1D.isrunning():
                 self.calc_1D.stop()
+                ## stop just raises the flag -- the thread is supposed to 
+                ## then kill itself but cannot.  Paul Kienzle came up with
+                ## this fix to prevent threads from stepping on each other
+                ## which was causing a simple custom model to crash Sasview.
+                ## We still don't know why the fit sometimes lauched a second
+                ## thread -- something which should also be investigated.
+                ## The thread approach was implemented in order to be able
+                ## to lauch a computation in a separate thread from the GUI so
+                ## that the GUI can still respond to user input including
+                ## a request to stop the computation.
+                ## It seems thus that the whole thread approach used here
+                ## May need rethinking  
+                ##
+                ##    -PDB August 12, 2014                  
+                while self.calc_1D.isrunning():
+                    time.sleep(0.1)
             self.calc_1D = Calc1D(data=data,
                                   model=model,