Octave/backend synchronization

[John W. Eaton]

On 23-Jan-2008, Michael Goffioul wrote:

| I'd like to propose the following patch. The goal is to implement a
| basic symchronization
| scheme between octave and a graphics backend. The idea is not to implement a
| fully-featured multithread support, but at least to provide a way to
| perform rendering
| in a separate thread, without race condition problems. This is
| motivated by the fact
| that in some graphics system (like Java), the GUI event-loop run
| automatically in
| a separate thread; hence the redraw requests will occur in this separate 
thread.
| The proposed scheme allows to "lock" completely access to the graphics system
| and should be enough for rendering purposes (and maybe special actions like
| 3D rotation).
| 
| Note that it is not my intention to run callbacks (like when pushing a
| button) in
| a separate thread; these should be run synchronously with octave.
| 
| The proposed code contains only the Windows implementation. I leave the UNIX
| implementation for people able to compile and run it. I tried to keep
| the implementation
| as lightweight as possible.

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

Thanks,

jwe