Re: Octave/backend synchronization

[John W. Eaton]

On 25-Jan-2008, Michael Goffioul wrote:

| On 1/25/08, John W. Eaton <address@hidden> wrote:
| > | 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.
| 
| One final note maybe (before closing the subject). While implementing
| auto-locking in the set_X/get_X methods seems easier, it only avoids
| local problems. For instance it does not guarantee that 2 get_X calls
| within the same function body will return the same value. For
| instance, consider the following code executed in a separate thread:
| 
| void my_function (void)
| {
|   ...
|   x = props.get_X ();
| 
|   // do something
| 
|   x = props.get_X ();
|   ...
| }
| 
| The second get_X call might return something different, if another
| thread has call set_X in between. One workaround is to cache the
| returned value from the first call, but you have to know it...
| However, I admit this is a kind of corner case.

It seems to me that this would be a smaller problem than having to
remember when and where to insert lock/unlock calls.

If it is necessary to expose the lock/unlock calls, then we can do
it.  I would just like to avoid it if possible.

Would you like to go ahead and add the lock/unlock functions?

It seems it should also be relatively easy to modify the genprops.awk
script to insert calls in the set and get methods.

jwe