octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thread-safe access to graphic objects - proposal


From: Maciej Gajewski
Subject: Re: Thread-safe access to graphic objects - proposal
Date: Thu, 3 Jul 2008 14:27:46 +0200

> As I already mentioned, I proposed a locking scheme a few months
> ago. See http://www.nabble.com/Octave-backend-synchronization-td15038411.html
> for the complete thread. What I proposed is exactly what I proposed 6 months
> ago, except for the boost dependency.

Yes, this is exactly it, except of boost.
In this case, boost adds simplicity and portability. Also, adding
boost as dependency could open gates for more use of this library. But
if octave maintainers decide to avoid any additional dependencies,
above patch could be enriched with Unix/MacOSX locking (using
pthreads). But IMO boost fits better in octave design.

The thread also had some discussion about automatic locking in set/get
methods, but this concept, though tempting, has major flaws. First one
- more obvious  - is requirement for consistency. In many cases
multiple properties has to be in sync witch each other. Second - less
obvious but more dangerous - is object deletion. Main thread can
delete object while GUI thread accesses it's properties. So
technically adding lock to gh_manager and locking/unlocking manually
in various places seems to be the only solution.

So what ever happened to this patch? Why was it abandoned at the end?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]