[haiku-commits] Re: haiku: hrev46012 - headers/private/screen_saver src/kits/screensaver src/preferences/screensaver
- From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Wed, 04 Sep 2013 18:00:55 +0200
Am 03/09/2013 15:17, schrieb John Scipione:
Unfortunately this does not show the other thread that is holding the
lock but it shows that this is where the contention lies. The thread
holding the lock must be outside of ScreenSaver, I'm guessing it is on
the App Server side.
Guessing doesn't help -- without knowing about this thread and its
state, there is simply no conclusion to be made.
IOW while your commit works around the problem, it doesn't solve it.
Before knowing the root cause, one should not try to fix anything.
Could you please investigate why the deadlock happens and then fix it
for real? When you look at the issue using Debugger, you'll just have to
find another thread that doesn't do anything but waiting, and keeps the
window locked.
I chose this solution because by timing out trying to aquire the lock
here not only does this bug disappear but the app is much more
responsive as well because we've avoided the rendering delay (shown in
the first screen shot) trying to render a screen saver after you've
moved on to the next item in the list.
That could already be avoided by checking if the runner had been quit
already. This would not remove the deadlock, though, it would just be
more correct.
The question is who is locking the window long enough to make this
become a problem in the first place?
The problem with the solution you implemented is that the
ScreenSaverRunner that should run (ie. the last one clicked) might not
get the lock in time, and therefore simply quits, leaving the preview
non functional.
Bye,
Axel.
Other related posts:
