Re: [PATCH v2 18/25] lockfile: avoid transitory invalid states
- From
Johannes Sixt <j.sixt@viscovery.net>
- Date
- Apr 7, 2014, 06:16 UTC
- 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:
Show 13 quoted lines
> 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