Re: Octave/backend synchronization

[Michael Goffioul]

On Jan 24, 2008 8:32 AM, John W. Eaton <address@hidden> wrote:
> 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?

I'm not sure you'll gain anything. First, I think that you would have lock
in the get_X functions (otherwise, how can you avoid a property change
while you're accessing it?). I thought about that possibility, but found it
less lightweight (each property access would trigger a lock/unlock)
than the global approach I used. Moreover, this means that any manually
written set_X would need to include the lock, so you're still left with
reliability and maintenance issues.

Given these issues, I took a different global approach. The main ideas are:

1) it's the responsbility of any C++ code (typically a graphics backend)
to lock/unlock the graphics system when this is required; for instance,
a rendering event handler would look like

void handle_draw_event (draw_event *evt)
{
  gh_manager::lock ();

  // Do all rendering stuff

  gh_manager::unlock ();
}

2) on the octave-side, the only places where you have to put lock/unlock
are the builtin DEFUN (in graphics.cc), because these are the only entry
points from a user point of view: any code within the graphics system
derives from a call to one of these builtin DEFUN. As there aren'y many
of them, I found that the maintenance effort was pretty low.

Of course, this is only my opinion. If you prefer another approach, we
can go for it. I know I'll need some kind of locking mechanism in
JHandles (and basically, any integrated GUI that runs octave in a
separate thread will also need it), so I wanted to propose something
at early stage in the graphics code (re)development.

Michael.