Found by @mkortstiege, thanks ;) The modal dialog introduces a deadlock if called after the settings change. We don't know the root cause of this deadlock, but this shift workaround the issue.
Remove all PVR addons and disable/enable the PVR manager and you get the freeze.
[pvr] workaround a deadlock if no pvr addons exist and you activate t…
…he pvr manager
It would be most useful to know the cause - let's not bandaid these things.
We need backtraces, plus clear reasons for why it happens (i.e. what callbacks does the setting of that bool fire, and what do they fire etc?)
sure, backtrace: http://xbmclogs.com/show.php?id=244792 (thread 1 and 19)
the callback which is called after setting change https://github.com/xbmc/xbmc/blob/master/xbmc/pvr/PVRManager.cpp#L110
Right, makes sense. CPVRClients sets the setting which fires a call to XBMC.StopPVRManager via app-messenger (adds a threadmessage) and then goes on to call into ApplicationMessenger (another threadmessage is added) via the DoModal and sits waiting on the threadmessage's event.
Meanwhile, app thread runs the first threadmessage which calls CPVRClients::Stop() but ofcourse it can't stop as it's waiting on the event of the next threadmessage in the queue.
The fix solves this by reordering those threadmessages (second isn't done until DoModal() returns).
@Montellese, @opdenkamp comments/suggestions on alternates?
Seems to me we don't need to be waiting at all on this dialog - it's basically a "you did something wrong" to the user, but setting the bool setting like this is kinda asking for trouble?
@jmarshallnz i was wondering if this kind of deadlock could happen in other code parts as well. Always thought the root cause is outside of PVRClients/Manager.
Patterns used in PVR heavily couples GUI and core. Coarse grained locking
combined with raising dialogs all over the show is a recipe for disaster.
The window rewrite should alleviate the major culprit of the observers
raising dialogs off app thread. I'm sure there are plenty of other places,
but the window rewrite PR was too much of a pig to justify digging deeper
until it was in.
@jmarshallnz good to hear, now we are a little bit more familiar how the thread messages stuff works ;)
So this one is good to go?
I'd like to hear from @Montellese first.
this will do the trick
@t-nelson with the original code, observers never held locks and notifications were fired async, as I've explained to you on IRC already ;-) raising dialogs was fine in that situation.
I don't see a cleaner/easier solution around this. In this case it probably doesn't make much sense to stop the PVR manager through an app thread message (we're blocking anyway with the dialog) but that's probably not that easy to change.
jenkins build this please