[mythtv-commits] Ticket #12974: Auto expire has race condition

[MythTV]

#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