Re: Locking graphics system - GUI/octave synchronization

[Maciek Gajewski]

I have one small request: would it be possible to split 
graphics.cc/graphics.h(.in) int ofew smaller files? These files are huge, 
they compile like ages and are hard to work with.

It would be much easier to do any broad changes - like event handling, mutexes 
and uicontrols - having few smaller files.

Maciek Gajewski

Michael Goffioul wrote:
> Hi,
>
> I know this has been discussed before, but would anyone see a major problem
> or showstopper in adding a mutex-based locking system that would allow
> to globally lock the graphics system? (through the use of specific methods
> in gh_manager, like lock() and unlock()).
>
> I'm currently investigating the implementation of an event-queue in octave,
> which would allow a backend to post a callback from any thread, such that
> the callback is executed in the octave thread. During this posting, I need
> to check various things, like whether another callback is executing,
> whether it's interruptible, whether busyaction tells me to queue or discard
> the event... During these operations, I don't want the graphics system to
> change state, so a global locking scheme would really help.
>
> If anybody objects, then I'll integrate this in the graphics mq. This will
> be based on the proposal I made a few months ago and on the more recent
> proposal from Maciek.
>
> Bye,
> Michael.