Re: [PATCH 1/3] fdopen_lock_file(): access a lockfile using stdio
From: Torsten Bögershausen <hidden>
Date: 2016-06-15 23:02:38
On 01.10.14 13:14, Michael Haggerty wrote: [] Nice done, small comments inline
quoted hunk ↗ jump to hunk
diff --git a/lockfile.c b/lockfile.c index d27e61c..e046027 100644 --- a/lockfile.c +++ b/lockfile.c@@ -7,20 +7,29 @@ static struct lock_file *volatile lock_file_list; -static void remove_lock_files(void) +static void remove_lock_files(int skip_fclose)
Even if the motivation to skip is clear now and here, I would consider to do it the other way around, and actively order the fclose(): static void remove_lock_files(int call_fclose)
{
pid_t me = getpid();
while (lock_file_list) {
- if (lock_file_list->owner == me)
+ if (lock_file_list->owner == me) {
+ /* fclose() is not safe to call in a signal handler */
+ if (skip_fclose)
+ lock_file_list->fp = NULL;
rollback_lock_file(lock_file_list);
+ }
lock_file_list = lock_file_list->next;
}
}
+static void remove_lock_files_on_exit(void)
+{
+ remove_lock_files(0);What does "0" mean ? remove_lock_files(LK_DO_FCLOSE) ?
+}
+
static void remove_lock_files_on_signal(int signo)
{
- remove_lock_files();
+ remove_lock_files(1);And what does this "1" mean ? remove_lock_files(LK_SKIP_FCLOSE) ? We can even have an emum, or use #define