Re: Octave/backend synchronization

[Michael Goffioul]

On 1/24/08, John W. Eaton <address@hidden> wrote:
> A change like this is acceptable to me, but would it maybe be better
> to refactor the code so that the lock/unlock can be limited to a
> single class?  Maybe we could do that by making the bodies of the set,
> get, __get__, etc. functions static functions in the gh_manager class?
> Then the lock/unlock methods could be made private and users would not
> have to worry about the details of locking unless they are writing new
> functions for the gh_manager class.

This would mean that the rendering process would have to go through
the gh_manager class. Is this what you want?

> It seems to me that the code
> would be easier to maintain and more reliable if we could do that.
>
> Which objects/variables need to be protected?

Almost all objects and properties: rendering can potentially access
most of the properties. Rendering is really the main use case I'm
thinking about (all the rest should be done synchronously with octave).
The idea is "if an external backend performs rendering in a separate
thread, it has the possibility to lock the graphics system such that
no other thread can make changes while rendering is running". So
my idea was that the backend would be responsible for locking/unlocking
the graphics system; this does not fit well with making these functions
private.

Michael.