[mythtv-commits] Ticket #7603: mythfrontend can never connect to just waked up master backend

[MythTV]

#7603: mythfrontend can never connect to just waked up master backend
-------------------------------------+--------------------------------------
 Reporter:  bam <mybigspam@…>        |       Owner:  danielk 
     Type:  defect                   |      Status:  assigned
 Priority:  minor                    |   Milestone:  unknown 
Component:  MythTV - General         |     Version:  unknown 
 Severity:  medium                   |     Mlocked:  0       
-------------------------------------+--------------------------------------
Changes (by danielk):

  * owner:  ijr => danielk
  * status:  new => assigned


Comment:

 The problem is a little more complicated than just this problem. When this
 code was first ported to MythUI another thread should have been created
 since MythUI depends on the UI thread continuing to run while the
 reconnect is in progress. But reconnects are initiated by MythProto
 activity which is often initiated by MythProto calls in the UI thread.

 One solution is to have two code paths within the reconnect code, one for
 when it is called from within the UI and another for when it is called
 from another thread. Another solution is do reconnects in a dedicated
 thread and when a MythProto call is called while disconnected we wait
 while allowing the UI to update. A third solution is to use the new thread
 pool facilities within Qt4 instead of adding another dedicated thread and
 treating GetSetting() calls like we would with a dedicated thread.
 Finally, a fourth solution is to not allow MythProto calls in the
 UI thread; this one allows for the most elegant and least error prone code
 and the best UI responsiveness, but would require the greatest number of
 changes to the existing code.

 All of these solutions are more complicated than I would like and there is
 a danger in allowing the UI to update while we are reconnecting since the
 user may initiate some action which results in more blocking calls or
 tries to use uninitialized data. My first preference is to use the
 threadpool, but there is an additional danger there that the threadpool
 may already be full of qRunnables which make MythProto calls.

 I'm not promising to work on this myself anytime soon, mostly due to lack
 of time. But I will assign it to myself as I've thought about these
 issues. When I last worked on the reconnect code my primary goal was to
 get slave backends to function correctly again, frontends can always be
 restarted in the worst case scenario -- you don't lose any recordings
 while it's dithering.

 Please post any follow-on discussion in the mythtv-dev mailing list. I
 read all those messages even if I don't have time to reply right away.

-- 
Ticket URL: <http://svn.mythtv.org/trac/ticket/7603#comment:4>
MythTV <http://www.mythtv.org/>
MythTV