Re: Octave/backend synchronization

[John W. Eaton]

On 24-Jan-2008, Michael Goffioul wrote:

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

Yes, but that maintenance problem is limited to the graphics
properties classes, not the users of those classes.

| 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 ();
| }

I think the problem with this is that it would be easy to forget, and
then hard to debug.

To me, an analogous situation is reference counting.  It might be more
efficient if we could skip incrementing and decrementing reference
counts when they aren't actually necessary, but I wouldn't want
to have to remember that level of detail every time I used an
octave_value object.

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

For the scripting language, yes, there wouldn't be many places to
lock, though anyone adding a new C++ function that accesses graphics
properties would have to know about locking.

jwe