[mythtv] Ticket #7762: Autoshutdown slave feature enhanced

[Chris Pinkham]

* On Wed Feb 10, 2010 at 01:15:50PM -0600, David Engel wrote:
> On Wed, Feb 10, 2010 at 03:40:19PM -0000, MythTV wrote:
> > Comment(by cpinkham):
> > 
> >  Thanks for the feature enhancement, but there are a few things that I
> >  think need to be corrected before this patch can be accepted.  Here are
> >  the issues I noticed:
> > 
> >  1) You can't instantiate a Scheduler anywhere but the master.   Just
> >  calling DisableScheduling() still lets the main parts of the scheduler run
> >  but it doesn't fire off any recordings.  The
> >  Scheduler code is not guaranteed to be 'multi-backend-safe', meaning that
> >  it potentially could
> >  do things to the database that should only be done from the master
> >  Scheduler.  I don't think
> >  there is any code like this currently, but it's not something we want to
> >  deal with in the
> >  future.  Even the "mythbackend --printsched" functionality opens a
> >  connection to the master
> >  scheduler and downloads the list of scheduled recordings.  If
> >  Scheduler::CheckShutdownServer() is the only thing you need from the
> >  scheduler, then you can make this method static and call it as
> >  "bool status = Scheduler::CheckShutdownServer(0, idleSince,
> >  blockShutdown);" in your code.
> 
> Chris, this isn't entirely true.  We have at least two cases where we
> currently instantiate additional schedulers.  One is when the
> --testsched option is used with mythbackend.  Another is the preview
> schedule changes feature.  That being said, instantiating a scheduler
> should be generally avoided for the reasons you gave.

Shhhh.... :)

Thanks for the correction.

The preview feature at least operates on a temporary record table on the
master, so that's a special case that is a little different.  I wasn't
thinking of the --testsched which does use the normal tables.

--
Chris