octave-maintainers
[Top][All Lists]
Advanced

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

Re: Forked off GUI


From: Israel Herraiz
Subject: Re: Forked off GUI
Date: Fri, 02 Nov 2012 16:26:51 +0100
User-agent: Sup/git

Excerpts from Jacob Dawid's message of Fri Nov 02 09:06:17 +0100 2012:
> 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.
> 
> [...]
>
> 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.

I have done a test, introducing a delay inside the workspace view slot
that updates it, and you are right. It is totally thread safe. I
thought that the model could have changed while the slot is being
executed, because the signal and the slot are in different threads.

> The problem here is that the cost of determing whether the workspace has
> changed is higher than refreshing it rightaway.

Again, I have tested with huge workspaces (1k, 2k, 5k variables), and
you are right. It consumes more CPU not refreshing than
refreshing. The difference is notable with 5k variables. Not
refreshing introduces a noticeable delay in the keyboard input in the
terminal. With less than 1k variables, there is not much difference
though.

So my apologies, this was indeed a problem time ago (around June), and
I wrongly assumed it was one of the causes of the instability of the
GUI. But it seems to be totally fixed now.

Cheers,
Israel


reply via email to

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