Hi Gary, I've now managed to solve the MS Windows issue. Somehow, the uni-processor fabric was accidentally triggering a GUI race condition (but only under MS Windows) which the older relax code paths did not. I think this was completely accidental. For example running with the debugging flag -d, the test suite would pass. The GUI requires a lot of indirect wx.CallAfter() calls to queue up GUI updates, and this was one place where I'd missed this. You may have noted that I have implemented the observer design pattern - in one of these, updating the spin system GUI element, is where the bug was being triggered. This design pattern is very useful in a GUI for giving the user feedback (so the program doesn't look like it's crashed), but can be a source of racing. Anyway, this is now fixed so you don't need to look into it.
As for the abstraction of the multi-processor package, this is a great design as most relax developers don't have to work with all the problems of threads. The use of threads in the GUI serves another purpose though and I have kept a good code separation between the two. Unfortunately GUI developers have to work with dead-locks, racing, segfaults, etc - this is unavoidable. However to get a certain analysis to run on a cluster, you don't need to touch the GUI and the threading and locking concepts, thanks to the multi package :) I plan to keep this separation so that most users won't even know that there are threads. The 'gui' package only contains a thin layer which is the GUI sitting on top of the rest of relax which does all of the work. The threading only occurs in this thin layer, and the rest of relax should never see this. Cheers, Edward On 19 September 2011 17:34, gary thompson <[email protected]> wrote: > > > -------- Original Message -------- Subject: Re: The multi-processor > package and GUI threading, queuing, and locking. Date: Mon, 19 Sep 2011 > 14:07:15 +0100 From: Gary Thompson > <[email protected]><[email protected]> To: > Edward d'Auvergne <[email protected]> <[email protected]> > > On 09/19/2011 01:34 PM, Edward d'Auvergne wrote: > >>> That's great that you have time, to have this working properly is > >>> quite important. I didn't realise how much of an issue the merging of > >>> the multi-processor code and GUI code would be. I have now merged the > >>> multi-processor branch into the main 1.3 line, as well as the new GUI > >>> branch, and that is where the problems are. I think there are at > >>> least 2 problems currently occurring. The first has to do with the > >>> GUI tests: > >>> > >>> $ relax --gui-test > >>> > >>> I looks like that there is a clash of the wxPython App.MainLoop() and > >>> how the master processors of the multi package interact. There > >>> appears to be race conditions, even in the uni-processor fabric. This > >>> only occurs in the test-suite, I have just tested manual operation of > >>> the GUI which works, so this makes things more difficult. The problem > >>> was not existent in the gui_testing branch (svn co > >>> svn+ssh://[email protected]/svn/relax/branches/gui_testing/@14200 > ) > >>> until after the multi-processor code was merged. > >>> > >> I presume this problem is solved and it was due to either a deadlock or > >> calling the wx event loop outside of its main thread. Looking at the source > >> code there seems to be quite a bit of thread specific code(?) One of the > >> aims of the multiprocessor frame-work was to avoid directly waiting on > >> threads and locks etc. This is why the whole design is based round queues > >> and callbacks as they are quite simple to deal with and don't directly > >> expose any underlying threaded model. If you would like me to expand on > >> this more please do say. If there are still multi threaded issues please do > >> say and give some details of how to cause event loop problems or deadlocks > > Hi Gary, > > > > This problem is now solved on GNU/Linux and Mac OS X, though there is > > still something preventing the tests on MS Windows (I don't know if > > it's related). I fixed this by completely avoiding IO redirection on > > the Uni-processor fabric. I'm not sure exactly what was causing the > > problem. > Ok I can have a look at this under windows > > For a GUI, having threads is essential. > > > For example with a one to two > > week model-free calculation, you need the GUI to remain responsive and > > show how the calculations are going (the text output continually being > > updated, gauges pulsed or set, etc). Without this the GUI would > > become completely grey, be unresponsive, and give no feedback so that > > the user will think that the program has crashed. Therefore as the > > wx.App must run in the main thread, the calculations and other time > > consuming operations must be spawned in sub-threads for asynchronous > > operation. As far as I can see, this appears to not affect the > > multi-processor package as the package is insensitive to whether it is > > run through the main or a sub-thread. Threading, queuing, and locking > > are key concepts for GUI design, and we unfortunately need to work > > around this. This has taken me a long time to get right, as is > > expected with these painful concepts. > > All the above is true and very clear, what I am saying about the > multiprocessor package is that it is designed as a general queueing > package that opetares via events and callbacks and thus allows you to > run multiple threads without joining thread or other 'dangerous' > procedures. You get all the benefits of a threaded application but > don't have to think about threads... > > > > The threading code is isolated to the 'gui' directory, and is only > > used in the auto-analyses and in the user functions accessed through > > the GUI (via the GUI interpreter thread). I think in both cases, the > > multi-processor code would operate normally. This package is > > currently only used for the grid() and minimise() user functions for > > model-free analysis. In this case, locking occurs through the global > > execution lock either acquired by the auto-analysis or via the GUI > > user function, if performed manually. This is prior to the > > multi-processor code execution, and is then released once the analysis > > or the user function finishes respectively. This lock is needed so > > that the GUI does not go grey, but prevents the user from running more > > than one thing at once. If relax is run with the debugging flag > > (relax -gd), then all locking information is printed to STDOUT. > > thats useful to know ;-) > > > > As for the IO redirection problem, I will address this in a second post. > > Ok I look forward to that > > regards > gary > > > > Cheers, > > > > Edward > > > -- > ------------------------------------------------------------------- > Dr Gary Thompson [Homans Lab Research Coordinator] > > Astbury Centre for Structural Molecular Biology, > University of Leeds, > Leeds, LS2 9JT, West-Yorkshire, UK Tel. +44-113-3433024 > > email: [email protected] Fax +44-113-3431935 > ------------------------------------------------------------------- > > > > > _______________________________________________ > relax (http://nmr-relax.com) > > This is the relax-devel mailing list > [email protected] > > To unsubscribe from this list, get a password > reminder, or change your subscription options, > visit the list information page at > https://mail.gna.org/listinfo/relax-devel > >
_______________________________________________ relax (http://nmr-relax.com) This is the relax-devel mailing list [email protected] To unsubscribe from this list, get a password reminder, or change your subscription options, visit the list information page at https://mail.gna.org/listinfo/relax-devel
