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://bugman@xxxxxxxxxxx/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
The multi-processor package and GUI threading, queuing, and locking.