octave-maintainers
[Top][All Lists]
Advanced

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

Re: Race condition seems to be fixed


From: Jacob Dawid
Subject: Re: Race condition seems to be fixed
Date: Mon, 21 May 2012 10:59:23 +0200

Sorry Michael,

I read you message too late.

Jacob,

I'm glad you found a workaround, although I would have liked to pinpoint the real problem, as (proper) atomic refcount should have avoided the race condition.

There is an ugly thing about that: What I did previously was to open a separate thread that was polling the symbol table in octave. Now the GUI model only gets updated when octave thinks it is worth to do that. We can discuss whether we can reduce this somehow, but as it is right now feels kind of "snappy" to me. Anyways, I like the idea of octave deciding whether to update or not.
 
Regarding your proposal, as John said, it's not generic enough. For instance you're missing any executed readline input hooks. This is typically used in the backends to execute handlers. This design looks very similar to what was done in OctaveDE. At this point, I think your best bet would be to install your own readline input hook. Ideally, this hook should be as light as possible (when there's nothing to be done) to avoid octave consuming CPU in idle state.

Michael.
 
Let's see how that works out, okay? We can still improve on that or remove it if it is bad.

Greetings,
Jacob

reply via email to

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