Octave/backend synchronization

[Michael Goffioul]

Hi,

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.

Michael.

src/ChangeLog

2008-01-23  Michael Goffioul <address@hidden>

    * graphics.h.in (class gh_manager): New static methods lock/unlock
    and instance methods do_lock/do_unlock.
    * graphics.cc (class gh_manager): Likewise (Windows implementation).
    (Fishandle, Fset, Fget, F__get__, F__go_figure__, F__go_axes__,
    F__go_line__, F__go_text__, F__go_image__, F__go_surface__,
    F__go_patch__, F__go_delete__, F__go_axes_init__,
    F__go_handles__, F__go_figure_handles__, Fdrawnow,
    get_property_from_handle, set_property_in_handle): Use locking
    mechanism.