tech-userlevel archive

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

Re: Library support for two-phase daemonization



In article <21230.27019.763030.648476%guava.gson.org@localhost>,
Andreas Gustafsson  <gson%gson.org@localhost> wrote:
>Anthony Mallet wrote:
>> Yes, I was suggesting this pattern as an alternative implementation of your
>> daemon_{fork,detach} with pipe(). 
>> 
>> Your suggestion solves one problem (the first use case above), and since you
>> are planning to add this to libc, it may be worth trying to solve the
>other use
>> case at the same time?
>> 
>> The API could be something like:
>>  - daemon_fork()
>>  - daemon_detach()
>> 
>>  - daemon_spawn(): basically a posix_spawn() with the additional signal
>>  notification pattern.
>
>I'm afraid I still don't see why this is needed.  Is there currently
>code in NetBSD using this pattern?  What advantages does it offer over
>traditional daemonization?

This pattern is necessary for any threaded deamon and has been open-coded
in all such daemons (see dhclient, named, etc.)

>Also, I'm specifically not trying to redesign or replace the existing
>daemonization API, but just to provide the minimum functionality
>needed to fix race conditions in existing NetBSD daemons.  If you
>believe that can be better achieved with signals than with pipes, I'm
>interested in hearing your arguments, but I'm not really interested in
>solving any unrelated problems.

file descriptors are better than signals because they can pass state (where
that is needed) and offer better control semantics (like a parent that
can spawn many children that waits until all of them have been initialized
before it exits). This is one more reason to pass the file descriptor
back to the parent like joerg suggested.

christos



Home | Main Index | Thread Index | Old Index