octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Forked off GUI


From: Jacob Dawid
Subject: Re: Forked off GUI
Date: Fri, 2 Nov 2012 09:06:17 +0100


I have been inspecting the current GUI. I think one of big issues for
the stability of the GUI is how events are managed. Currently, there
is a semaphore that avoids accessing the events queue from two
different threads. However, all the events are processed without any
kind of semaphore or lock.

I am pretty sure I wrote a threadsafe access function to avoid that. When did you fork? It might be that you catched me in an early state of development.
 
Thus, if we take the workspace view as an
example, if for some reason the workspace takes a little longer to be
updated, the next event updating the workspace view will try to update
it while it's still being updated. That also happens with the commands
history view.

That's not true. You have overseen that only a new update will be send when the old one has been processed. I have set up a timer which is a single shot timer, so it will only fire after a given time. At construction time the timer will be activated, sending an update request after some given time, then stops. Upon update, the timer will be reactivated again and so on.
 
A semaphore in all the code updating any of the windows
would avoid some stability problems. Those semaphores would be
additional to the current semaphores avoiding concurrent access to the
events queue.


This would lead to deadlocks. I tried that.
 
Also, the model should be changed to avoid refreshing the workspace
view if the model has not changed (currently, it always refreshes
every 0.5 seconds).


The problem here is that the cost of determing whether the workspace has changed is higher than refreshing it rightaway.
 
I think these two changes are the main differences that could be
useful to improve the stability of the GUI. Other differences are
merely cosmetic, or do not impact on stability (I have finished the
GUI for the debugger for instance, and it is now functional).


These I problems I faced during development. I strongly suggest that you try them first, but in my case they were not beneficial.
 
I have done those two changes in my code, and after an inspection of
the current GUI code, I think I could easily integrate that. Or at
least, helping someone else integrating that using my code as a base.

Did you actually compare the current GUI in performance (ie. CPU usage etc.) with the current GUI? Try loading extremely big workspaces, like create 10000 different named variables. I tested with such cases.

Jacob

reply via email to

[Prev in Thread] Current Thread [Next in Thread]