Re: Octave/backend synchronization

[John W. Eaton]

On 24-Jan-2008, Michael Goffioul wrote:

| 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.

What I'm thinking about is that if the users of the graphics objects
must know when to call the lock/unlock functions, and that they must
do it in many places, then I think we will end up with reliability and
maintenance problems.

What about restricting access to the properties via set_X and get_X
functions?  If we do that, couldn't we put the locking in the set_X
functions so that the backend code would not have to deal with locking
directly?

jwe