[Mailman-Developers] problem with view other subscriptions..

[Barry A. Warsaw]

    HM> I still don't see why there's a need for the "intermediate"
    HM> state (neither fully locked nor fully unlocked) with the
    HM> shared lockfile having a link count of 1.  I think it just
    HM> makes the locking logic more complicated to understand.

You've convinced me.  I'm about to check in a bunch of changes,
including some to LockFile.py in which I've basically installed your
patch.  The one thing I'm not sure about is removing the try/except
around the unlink of winner -- I think there's still a race condition
where winner could be non-empty but the unlink could fail.  The
try/except shouldn't hurt so I'm leaving that one thing in.

    HM> The other method that currently unlinks the shared lockfile is
    HM> __break().  The purpose of that method is to remove lockfiles
    HM> that some other process has failed to release within the
    HM> lock's lifetime.  Thus, this method breaks the invariant you
    HM> mention *by design*.

I think __break() is fundamentally broken.  Actually, I think breaking
locks gets us into all kinds of problems.  But there's the trade-off
of deadlocking the whole system for something we haven't thought
about.

One approach might be to never break locks implicitly, but have
qrunner (which now runs every minute) check for long-dead locks and
send warning emails to the site admin.  A simple rm should clear up
the problem.

As an interim approach, I'm just cranking up the qrunner and list lock
lifetimes to really big numbers (like 10 hours and 5 hours
respectively).  Hopefully, in conjunction with some other soon to be
checked in changes, this will help many of the problems that I think
are premature-lock-breaking related.

All this is just whacked anyway.  What we really need is a
transactional database underneath so we wouldn't need all these stupid
list locks.  I still believe that's too much work for 2.0, but as this
beta3 drags on, I'm starting to have doubts.

-Barry