Re: [PATCH 1/3] fdopen_lock_file(): access a lockfile using stdio

["Torsten Bögershausen" <tboegi@web.de>]

On 01.10.14 13:14, Michael Haggerty wrote:
[]
Nice done, small comments inline
> 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
>