-------- Original Message --------
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://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.
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: garyt@xxxxxxxxxxxxxxx Fax +44-113-3431935
-------------------------------------------------------------------
|
Fwd: Re: The multi-processor package and GUI threading, queuing, and locking.