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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to