New library: libpidfile.

[Peter Jeremy]

Firstly, I think that this is useful.  Writing code to correctly
ensure that no more than one copy of a process is running is very easy
to get wrong - and I've seen lots of examples of how not to do it.

On Tue, 2005-Aug-23 10:17:58 +0200, Pawel Jakub Dawidek wrote:
>In my first concept (when it was part of libutil) I allocated memory
>to store needed informations, because I didn't wanted to use preallocated
>memory (someone linking libutil doesn't have to use pidfile
>functionality).

Since there's an initialisation function, why not just malloc whatever
memory you need?  You can either store the pointer in a local static
or have pidfile_open() return it as an opaque pointer that the user
has to pass into other pidfile_XXX functions.

>It also now has 4 functions, which makes it a good candidate of small,
>nice, lightweight library:)

IMHO, 4 functions is too small.  I would prefer to have a smaller
number of larger libraries and think this belongs in an existing
library - eg libutil.  Whilst this may form a nice lightweight
library, if everyone wrote small, lightweight libraries, linking
an application would require a mile-long command line.

Can I suggest two enhancements:
1) Allow NULL to be passed to pidfile_open() to indicate that the
   pidfile should be in /var/run/PROCESS_NAME.pid (and/or if the
   name doesn't include any '/' then default to /var/run)
2) Write a wrapper function that calls pidfile_open() and if it's
   successful, exec's the rest of the command line.

-- 
Peter Jeremy