tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pidfile_lock(3)



In article <1547312.W6Y7Ml981D%uberpc.marples.name@localhost>,
Roy Marples  <roy%marples.name@localhost> wrote:

There is no need for pidfile_lock(), just fix pid_file() to return pid_t.
I've audited the code in the tree and the code that checks, checks for -1.
The compat code below is probably wrong anyway.

christos

>+/* The old function.
>+ * Historical behaviour is that pidfile is not re-written
>+ * if path has not changed.
>+ *
>+ * Returns 0 on success, otherwise -1.
>+ * As such we have no way of knowing the pid who owns the lock. */
> int
> pidfile(const char *path)
> {
>+	pid_t pid;
> 
>-	if (path == NULL || strchr(path, '/') == NULL) {
>-		char *default_path;
>-
>-		if ((default_path = generate_varrun_path(path)) == NULL)
>-			return -1;
>-
>-		if (create_pidfile(default_path) == -1) {
>-			free(default_path);
>-			return -1;
>-		}
>-
>-		free(default_path);
>-		return 0;
>-	} else
>-		return create_pidfile(path);
>+	pid = pidfile_lock(path);
>+	return pid == 0 ? 0 : -1;
> }
>
>-=-=-=-=-=-





Home | Main Index | Thread Index | Old Index