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