[mythtv] Scheduler needs table keys?

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Thu Mar 1 06:36:54 UTC 2007


    Date: Thu, 1 Mar 2007 01:12:13 -0500
    From: Chris Pinkham <cpinkham at bc2va.org>

    > > there's no way that mainserver could lock up the table long enough to
    > > cause dropped data, but I'll test it by rebooting a frontend and
    > > selecting Watch Recordings while something is recording, and see
    > > if that corrupts it.  [Can you think of a more-strenuous test I should
    > > try instead?]  If not, I'll leave it alone.

    > Mainserver should be doing queries mainly so it won't lock, although it
    > might get locked.  It does update the filesize, but that only takes
    > a short while, so a long query running somewhere else (ie, the scheduler)
    > with a parallel SetFilesize() call in mainserver, could cause another
    > query to block waiting for the set to finish (which is waiting on the
    > scheduler's query to finish).  I tested and documented this scenario
    > in the other thread a while back.

I'm having difficulty finding that analysis (looking in my mail from
the last couple of months for mainserver isn't finding it); if you
can find it easily, can you yank it into a reply?

I guess my real question wrt your paragraph above is, "Would such
locks propagate down to hanging ProcessData if -it- is not also
trying to update filesize?"  I don't see how, but I haven't looked
carefully.  If the scheduler can lock out the expirer, or even the
UI, I don't care so much (sure, a 15-second pause waiting for the
UI to put up the Watch Recordings screen might be annoying, but it
won't kill recorded data), but if the scenario somehow locks the
capture thread, I guess I should be commenting out more calls to
SetFilesize. :)

---or is what you're saying, "if I go to Watch Recordings for the
first time since some recording has started [e.g., nothing else has
set filesize, so mainserver sets it for use by the FE], and if I did
so while the scheduler happened to be running, then mainserver could
hang trying to update the filesize, -and- this hang could then hang
ProcessData"?  Are these in the same thread?  It's certainly
conceivable that I'd happen to trip over this (since presumably
it's likely to go to Watch Recordings right after deleting something,
and that means the scheduler will have kicked off), so if this is a
potential failure mode, I'll comment out the SetFilesize calls in
mainserver as well.  [I -never- look at recorded.filesize in -any-
part of the UI except for what MythWeb shows me in its Recorded
Programs page---and again, if computing that page could hang -capture-
because of a lock on recorded.filesize, I'll remove the mainserver
call.  I presume I don't care if the call in FinishRecording hangs
even for 30 seconds, since -that- thread is done and presumably the
other recordings are being handled by different threads?  Would having
FinishRecording hanging tend to cause a sequence of scheduler runs as
each one hangs the next-ending recording? (If they all end simultaneously.)
Do we care? :)

P.S.  ...hmm.  Yeah, I guess one fallout of nuking ProcessData's
SetFilesize -is- going to be that MythWeb's recordings page will list
a size of 0 for any in-progress recording, since I'm assuming it's
getting that info from the DB & not doing a stat.  I think I can
live with that. :)


More information about the mythtv-dev mailing list