[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Octave/backend synchronization
From: |
John W. Eaton |
Subject: |
Re: Octave/backend synchronization |
Date: |
Thu, 24 Jan 2008 02:32:51 -0500 |
On 24-Jan-2008, Michael Goffioul wrote:
| On 1/24/08, John W. Eaton <address@hidden> wrote:
| > A change like this is acceptable to me, but would it maybe be better
| > to refactor the code so that the lock/unlock can be limited to a
| > single class? Maybe we could do that by making the bodies of the set,
| > get, __get__, etc. functions static functions in the gh_manager class?
| > Then the lock/unlock methods could be made private and users would not
| > have to worry about the details of locking unless they are writing new
| > functions for the gh_manager class.
|
| This would mean that the rendering process would have to go through
| the gh_manager class. Is this what you want?
|
| > It seems to me that the code
| > would be easier to maintain and more reliable if we could do that.
| >
| > Which objects/variables need to be protected?
|
| Almost all objects and properties: rendering can potentially access
| most of the properties. Rendering is really the main use case I'm
| thinking about (all the rest should be done synchronously with octave).
| The idea is "if an external backend performs rendering in a separate
| thread, it has the possibility to lock the graphics system such that
| no other thread can make changes while rendering is running". So
| my idea was that the backend would be responsible for locking/unlocking
| the graphics system; this does not fit well with making these functions
| private.
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?
jwe
- 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 <=
- Re: Octave/backend synchronization, Michael Goffioul, 2008/01/24
- 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