[mythtv-commits] Ticket #12974: Auto expire has race condition
MythTV
noreply at mythtv.org
Wed Feb 1 18:05:36 UTC 2017
#12974: Auto expire has race condition
----------------------------------+------------------------
Reporter: amb@… | Owner:
Type: Bug Report - General | Status: new
Priority: minor | Milestone: 29.0
Component: MythTV - General | Version: 0.28.0
Severity: medium | Resolution:
Keywords: | Ticket locked: 0
----------------------------------+------------------------
Comment (by mdean):
FWIW, I'm not a fan of the time-based approach to ignoring deletepending
flag--especially with such a short time.
The approach I had considered using several years ago to work around this
race condition (since it's likely that many people--primarily those who
don't have have slow deletes enabled, since the time allowing this race to
be hit when slow deletes is enabled is negligible--have one or more stuck
files) was to have the autoexpire thread pick up all deletepending
recordings on master backend startup and restart deleting them.
Unfortunately, I didn't get around to testing how it would work/how to
handle the case where the user has multiple backends and the master
backend is restarted while remote backends are in the process of deleting
files. This has the benefit of defining a simple condition under which
deletepending is invalid (when the system is just starting up), and it
won't be affected by system speed/deletion speed/...
A better approach is to avoid the race condition altogether, rather than
work around it--though we'll still need clean-up code, as above, for the
old files on people's systems. It may well be that now that the Deleted
recording group is always used as a means of providing a delete queue for
MythTV, that we can change deletepending to be a UI-only field, now, and
when a recording is deleted, simply move it to the Deleted recording group
(if not already there) to serve the old purpose of deletepending. So,
that means that the "WHERE %1 AND deletepending = 0" that you modified in
autoexpire.cpp could remove the deletepending reference (leaving "WHERE
%1"). However, it may also mean that we'd need to add code to the
autoexpirer to remember (in memory) that it's currently deleting some
given file so it can remove that file from the deleteList. I haven't
explored this particular avoid-the-race-condition idea in detail, so
comments/suggestions/reasons why it won't work are welcomed.
--
Ticket URL: <https://code.mythtv.org/trac/ticket/12974#comment:2>
MythTV <http://www.mythtv.org>
MythTV Media Center
More information about the mythtv-commits
mailing list