Changeset f3efa09 in sasview


Ignore:
Timestamp:
Jan 25, 2015 11:39:26 AM (8 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:
b52f47f, 5972029
Parents:
5ba88d3
Message:

Fix Pr failure ticket #273


Long version: In August 2013 it was determined that many instability problems experienced by SasView? were do to a threading problem in fitting.py. Mainly the authors seemed to not realize that calling thread.stop just raised a flag and that the thread itself needed to check for said flag regularly and kill the thread if it found the flag raised. A quick fix was implemented by adding a wait till the existing thread ended naturally to the two places in the code where the stop is raised. This seems to work.

At the same time pr.py was found to use the same raising of the stop flag three times and it was assumed that the same problem existed and the same wait “fix” was implemented. Subsequenty it has been shown that the new wait code in pr.py NEVER gets reached and thus the fix breaks the PrView? perspective. It may be that this earlier code properly dealt with threads properly(still remembering how the thread code was meant to be used). Whatever the case will remove this fix for now.

Finally another thread.stop was found once in simulation.py. since this is older code it may also be handled properly so am removing the “Fix” from that as well for now.

to quickly find these points in the future:
fitting.py - two instances that seem to need fixing
pr.py - three instances that may work correctly
simulation.py - one instace

search terms:
“-PDB” or
“d.stop” (thread.stop or thread_1D.stop or 2D.stop)

Location:
src/sans/perspectives
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • src/sans/perspectives/pr/pr.py

    rf4167637 rf3efa09  
    725725            self.calc_thread.stop() 
    726726            ## stop just raises the flag -- the thread is supposed to  
    727             ## then kill itself but cannot.  Paul Kienzle came up with 
    728             ## this fix to prevent threads from stepping on each other 
    729             ## in Calc1D of fitting.py which was causing a simple custom model 
    730             ## to crash Sasview.  See rest of notes under Calc1D. 
     727            ## then kill itself. In August 2014 it was shown that this is 
     728            ## incorrectly handled by fitting.py and a fix implemented.  
     729            ## It is not clear whether it is properly used here, but the 
     730            ## "fix" of waiting for the previous thread to end breaks the 
     731            ## pr perspective completely as it causes an infinite loop. 
     732            ## Thus it is likely the threading is bing properly handled. 
     733            ## While the "fix" is no longer implemented the comment is 
     734            ## left here till somebody ascertains that in fact the threads 
     735            ## are being properly handled. 
    731736            ## 
    732             ##    -PDB August 13, 2014                   
    733             while self.calc_thread.isrunning(): 
    734                 time.sleep(0.1) 
     737            ##    -PDB January 25, 2015                   
    735738                 
    736739        pr = self.pr.clone() 
     
    11531156            self.estimation_thread.stop() 
    11541157            ## stop just raises the flag -- the thread is supposed to  
    1155             ## then kill itself but cannot.  Paul Kienzle came up with 
    1156             ## this fix to prevent threads from stepping on each other 
    1157             ## in Calc1D of fitting.py which was causing a simple custom model 
    1158             ## to crash Sasview.  See rest of notes under Calc1D. 
     1158            ## then kill itself. In August 2014 it was shown that this is 
     1159            ## incorrectly handled by fitting.py and a fix implemented.  
     1160            ## It is not clear whether it is properly used here, but the 
     1161            ## "fix" of waiting for the previous thread to end breaks the 
     1162            ## pr perspective completely as it causes an infinite loop. 
     1163            ## Thus it is likely the threading is bing properly handled. 
     1164            ## While the "fix" is no longer implemented the comment is 
     1165            ## left here till somebody ascertains that in fact the threads 
     1166            ## are being properly handled. 
    11591167            ## 
    1160             ##    -PDB August 13, 2014                   
    1161             while self.estimation_thread.isrunning(): 
    1162                 time.sleep(0.1) 
     1168            ##    -PDB January 25, 2015                   
    11631169                 
    11641170                 
     
    11811187            self.estimation_thread.stop() 
    11821188            ## stop just raises the flag -- the thread is supposed to  
    1183             ## then kill itself but cannot.  Paul Kienzle came up with 
    1184             ## this fix to prevent threads from stepping on each other 
    1185             ## in Calc1D of fitting.py which was causing a simple custom model 
    1186             ## to crash Sasview.  See rest of notes under Calc1D. 
     1189            ## then kill itself. In August 2014 it was shown that this is 
     1190            ## incorrectly handled by fitting.py and a fix implemented.  
     1191            ## It is not clear whether it is properly used here, but the 
     1192            ## "fix" of waiting for the previous thread to end breaks the 
     1193            ## pr perspective completely as it causes an infinite loop. 
     1194            ## Thus it is likely the threading is bing properly handled. 
     1195            ## While the "fix" is no longer implemented the comment is 
     1196            ## left here till somebody ascertains that in fact the threads 
     1197            ## are being properly handled. 
    11871198            ## 
    1188             ##    -PDB August 13, 2014                   
    1189             while self.estimation_thread.isrunning(): 
    1190                 time.sleep(0.1) 
     1199            ##    -PDB January 25, 2015                   
    11911200                                 
    11921201        pr = self.pr.clone() 
  • src/sans/perspectives/simulation/simulation.py

    rf4167637 rf3efa09  
    214214            self.calc_thread_1D.stop() 
    215215            ## stop just raises the flag -- the thread is supposed to  
    216             ## then kill itself but cannot.  Paul Kienzle came up with 
    217             ## this fix to prevent threads from stepping on each other 
    218             ## in Calc1D of fitting.py which was causing a simple custom model 
    219             ## to crash Sasview.  See rest of notes under Calc1D. 
     216            ## then kill itself. In August 2014 it was shown that this is 
     217            ## incorrectly handled by fitting.py and a fix implemented.  
     218            ## It is not clear that it is improperly used here so no fix 
     219            ## is being added here. 
    220220            ## 
    221             ##    -PDB August 13, 2014                   
    222             while self.calc_thread_1D.isrunning(): 
    223                 time.sleep(0.1) 
     221            ##    -PDB January 25, 2015                   
    224222             
    225223        # Create a computation thread 
Note: See TracChangeset for help on using the changeset viewer.