|
From: | Daniel J Sebald |
Subject: | Re: using timers in the GUI |
Date: | Mon, 18 Feb 2013 22:34:59 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
On 02/18/2013 12:45 PM, Torsten wrote:
On 18.02.2013 19:03, Jacob Dawid wrote:Yeah, I don't understand the point of the timer either. Wouldn't it be sufficient to just perform the update when the Octave interpreter is at points where it is safe to perform updates? For example, in the readline callback when Octave is waiting for input and perhaps some other select locations. Jacob, could you comment about why you chose to use a timer for this purpose?That's pretty complicated. As far as I recall, the problem was that Qt's model/view mechanism is not - different from what I initially supposed - threadsafe. The updating of the model has to be done from within the Qt thread. As I experienced crashes because of that, I sequenced the access to a specific "intermediate" memory by semaphores (basically just a simplified version of a symbol list). The octave symbol table is queried and the intermediate memory updated whenever the interpreter is ready and the intermediate memory is *not read* by the Qt thread (otherwise it would wait for the Qt thread to finish its job). At times, where the octave interpreter is not accessing the intermediate memory (ie. writing), the Qt thread periodically updates the model based on the intermediate memory. Since there is no guarantee that the procedure invoked by the timer will be finished within an interval, the timer is a single shot timer. It will only fire once, then the timer is restarted by the procedure when the model has been fully updated. That guarantees idle times between updates.In order to make the updating work within mxe-octave, I changed the timer setup with changeset http://hg.savannah.gnu.org/hgweb/octave/rev/0486a29d780f Since the timer can not be started in the callback function, the timer was changed into a periodic one and instead, there is a flag for enabling and disabling the update. When the timer finishes, the update event is fired only if updates are enabled. With firing the event, subsequent updates are disabled (by ignoring the timer) and re-enabled at the end of the callback function (where the single shot timer was restarted by now). Torsten
Well that's a good solution to that problem. Yet there is still the issue that John and I are wondering about: whether a timer is the way to go to update the workspace variable tree. A couple issues:
1) It is somewhat inefficient to be updating the workspace so often. From the code, it appears that the workspace tree is rebuilt every half second if Octave is sitting idle at the command line. If one's workspace variables become numerous, not a difficult thing, that could be a lot of unnecessary machine cycles. Being event driven is more efficient.
2) The sampling method precludes any possibility for a feature that highlights in bold or another color variables which change value between the readline and other select locations that John mentions. What are other select locations? Breakpoints. Often simulators and emulators have the feature I just mentioned, i.e., change the appearance of variables that change between two idle moments. I'm not sure that is a feature that some would like to have, but I suspect it might be one of those things that until it comes along one doesn't know how much they would miss it.
Continuing with item 2, it could be the case such a feature isn't possible with the way Octave is currently set up. I have no idea. One way would be to do a variable-by-variable comparison in the GUI code. A before and after tree, as it were. Another approach is that if John could make the variable table shared memory and include some flag for each variable that is changed or added whenever the value of that object changes, it might be easier to figure out. Then again, setting such a flag again-and-again within a big loop might be less efficient than just doing a before and after variable comparison. That design element can be a future project, but I think that using some method other than a timer would be a good change early on.
Dan
[Prev in Thread] | Current Thread | [Next in Thread] |