[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Octave/backend synchronization
From: |
Michael Goffioul |
Subject: |
Re: Octave/backend synchronization |
Date: |
Thu, 24 Jan 2008 11:38:09 +0100 |
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.
- Octave/backend synchronization, Michael Goffioul, 2008/01/23
- Re: Octave/backend synchronization, Michael Goffioul, 2008/01/23
- Octave/backend synchronization, John W. Eaton, 2008/01/23
- Re: Octave/backend synchronization, Michael Goffioul, 2008/01/24
- Re: Octave/backend synchronization, John W. Eaton, 2008/01/24
- Re: Octave/backend synchronization,
Michael Goffioul <=
- Re: Octave/backend synchronization, John W. Eaton, 2008/01/25
- Re: Octave/backend synchronization, Michael Goffioul, 2008/01/25
- Re: Octave/backend synchronization, Michael Goffioul, 2008/01/25
- Re: Octave/backend synchronization, John W. Eaton, 2008/01/25