tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Library support for two-phase daemonization
Christos Zoulas wrote:
> In article <21230.27019.763030.648476%guava.gson.org@localhost>,
> Andreas Gustafsson <gson%gson.org@localhost> wrote:
> >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.)
Are we talking about the same pattern? I was referring to the latter
of Anthony's two use cases:
| > I choosed this approach so that the program can be used according two
distinct
| > use cases:
| > - classic standalone mode, start within a shell script: daemonize with a
| > command line switch and return to the shell only once the program is
ready.
| >
| > - start from another unrelated "launcher" program. The launcher must of
course
| > implement the 'SIGUSR1' logic. In this mode, the child does not fork
itself,
| > but it is still able to inform it's parent about it 'ready' state. (think
| > for instance about inetd, although it's not inetd in my use case).
That latter pattern is not used in dhclient nor named.
> file descriptors are better than signals because they can pass state (where
> that is needed) and offer better control semantics
Agreed.
> (like a parent that
> can spawn many children that waits until all of them have been initialized
> before it exits).
Yes, pipes are better for that, too, but I don't think that case is common
enough to warrant library support.
> This is one more reason to pass the file descriptor back to the
> parent like joerg suggested.
I don't see any such proposal from Joerg - he proposed returning the
file descriptor from deaemon2(), which amounts to passing it to the
child, not the parent.
--
Andreas Gustafsson, gson%gson.org@localhost
Home |
Main Index |
Thread Index |
Old Index