On Wed, Aug 12, 2009 at 17:03, Max Kellermann wrote:
> On 2009/08/12 22:48, Mike Frysinger wrote:
>> however, there is still one use of fork() in the mpd source code in
>> the daemonize_detach() function. really this function should get
>> punted and daemonize() should simply call the C library's daemon(0,1).
>> the daemon() function has existed since BSD 4.4, so for all realistic
>> *nix targets, this function should be fine.
>
> What is the advantage of daemon(), and what is the problem with
> fork()?
daemon() works on no-mmu systems and does all the magic you're already
coding in daemonize_detach(). no-mmu systems cannot implement fork(),
but they can implement daemon().
> daemon() is not defined in any standard. I'd like to avoid
> non-standard functions.
C libraries dont change semantics of well established functions --
which daemon() is. ABI's get locked in stone for sane C libraries.
> Since we have to implement a fallback anyway,
> we cannot save a single line of source by using daemon().
i dont really know what you mean, but if you only want this logic for
people who need it, it's trivial to do:
- add fork to AC_CHECK_FUNCS in configure.ac
- change src/daemon.c to look like:
static void
daemonize_detach(void)
{
#ifdef HAVE_FORK
... current code ...
#else
daemon(0, 1);
#endif
}
-mike
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
