>> 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. 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. 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. As for the IO redirection problem, I will address this in a second post. Cheers, Edward _______________________________________________ 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
