octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Octave/backend synchronization


From: Shai Ayal
Subject: Re: Octave/backend synchronization
Date: Wed, 23 Jan 2008 13:29:17 +0200

On Jan 23, 2008 12:17 PM, Michael Goffioul <address@hidden> wrote:
> This time, with the attachment...
>
> Michael.
>
>
>
> On Jan 23, 2008 10:55 AM, Michael Goffioul <address@hidden> wrote:
> > 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.

I have zero knowledge in multithreading, but I did find this:
http://www.gamasutra.com/features/20051205/paquet_pfv.htm
which seems to provide a way to translate between the windows code
Michael has written and linux system calls

does anyone know aht is the situation in other OS's (OSX, solaris , ....?)

Shai



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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]