[haiku-commits] Re: BRANCH waddlesplash-github.tracker_cleanup_threads_properly [9749bc4c0ab9] src/kits/tracker

  • From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Sun, 30 Apr 2017 11:59:50 +0200

Am 30/04/2017 um 08:55 schrieb Ingo Weinhold:

Do you really have to do that? Can't you simply delete the lock
instead? That would be a good way to let lockers fail immediately.
Unless I really missed something, the lock is the looper lock for the
BPoseView, and this code will deadlock in the destructor unless there is
a mechanism for it to timeout. So, no, that's not an option.
I'm not familiar with the code in question, but generally, if you have
code paths with inverse locking order, the solution should be to fix
that, not to work around with timeouts.

In case I understand the problem correctly here, a possible solution would be a loop like this (in a hypothetical BPoseView::QuitRequested() method):

<starts locked>
        some shared quit bool = true
                // the poses thread will check for this, and exit
        while (poses threads left) {
                unlock;
                lock;
        }

Bye,
   Axel.

Other related posts: