From: Johannes Sixt <j.sixt@viscovery.net>
Date: Mon, 07 Apr 2014 06:16:12 GMT
Subject: Re: [PATCH v2 18/25] lockfile: avoid transitory invalid states
Message-ID: <534242AC.7030908@viscovery.net>
In-Reply-To: <1396827247-28465-19-git-send-email-mhagger@alum.mit.edu>

Am 4/7/2014 1:34, schrieb Michael Haggerty:
> Because remove_lock_file() can be called any time by the signal
> handler, it is important that any lock_file objects that are in the
> lock_file_list are always in a valid state.  And since lock_file
> objects are often reused (but are never removed from lock_file_list),
> that means we have to be careful whenever mutating a lock_file object
> to always keep it in a well-defined state.
> ...
> So, instead of encoding part of the lock_file state in the filename
> field, add a new bit "LOCK_FLAGS_LOCKFILE_ACTIVE" to flags, and use
> this bit to distinguish between a lock_file object that is active
> vs. one that is inactive.  Be careful to set this bit only when
> filename really contains the name of a file that should be deleted on
> cleanup.

Since this flag is primarily for communication between the main code and a
signal handler, the only safe way is to define the flag as volatile
sig_atomic_t, not to make it a bit of a larger type!

-- Hannes