[mythtv] Scheduler needs table keys?

[David Engel]

On Sun, Jan 28, 2007 at 04:59:47PM -0500, Chris Pinkham wrote:
> different ways to run a background SQL command.  I was tossing around
> the idea of a MSqlQuery::asyncexec() that would pass the SQL off to
> the background thread, that way you could call MSqlQuery::exec() to
> execute immedately/syncronously and MSqlQuery::asyncexec() to execute
> in the background.  I do think that both of these should be put into
> another thread as I've stated in other email threads. :)

We might also consider letting the recorder thread use real-time
scheduling.  That would help make sure it runs ASAP after the kernel
has data to be read.

> recording.  To accomplish this, filesize and basename would be moved
> to a 'recordedfile' table.  This table wouldn't need to be accessed by
> the scheduler so the contention would go away.  I don't think that this

Another way to remove contention would be to get rid of
kDupsInRecorded so the scheduler wouldn't have to touch the recorded
table.  You've objected to this in the past on grounds that someone
might want to record all duplicates but only if they're not currently
recorded.  I doubt such a contrived case is important enough to worry
about, but if it is, I wonder if it couldn't be handled some other way
-- say an option to automatically allow re-record after delete.

David
-- 
David Engel
david at istwok.net