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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html