Date: Tue, 16 Mar 2010 02:40:50 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Poul-Henning Kamp <phk@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r205165 - head/lib/libc/gen Message-ID: <20100316021240.N24765@delplex.bde.org> In-Reply-To: <201003150858.o2F8wZid011308@svn.freebsd.org> References: <201003150858.o2F8wZid011308@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 15 Mar 2010, Poul-Henning Kamp wrote: > Log: > Comment a fine point, so it does not get lost when people borrow code > from FreeBSD for other purposes. > > Modified: > head/lib/libc/gen/daemon.c > > Modified: head/lib/libc/gen/daemon.c > ============================================================================== > --- head/lib/libc/gen/daemon.c Mon Mar 15 00:29:15 2010 (r205164) > +++ head/lib/libc/gen/daemon.c Mon Mar 15 08:58:35 2010 (r205165) > @@ -64,6 +64,10 @@ daemon(nochdir, noclose) > case 0: > break; > default: > + /* > + * A fine point: _exit(0), not exit(0), to avoid triggering > + * atexit(3) processing > + */ > _exit(0); > } This point is obvious -- the programmer used _exit() for a reason, and reading _exit(3) gives the reason. _exit(3) only mentions atexit(3) cryptically as "etc.", but it makes it clear that there are more reasons than to avoid triggering atexit(3) -- exit(3) also does things like flushing open streams which are logically and possibly implementationally independent of atexit(3). They _should_ be implementationally independent to avoid bloating all programs with dynamic allocation of the atexit() table. The unobvious points are: - why avoid triggering atexit(), etc. processing in daemon()? - why isn't this documented? Some callers of daemon() need to know that it won't flush open streams, etc., so that they can flush and their open streams, etc., before calling daemon(). Callers should do this anyway before calling any function that can exit (especially exit() itself), so that they can actually check that the output went out, but most are sloppy. Callers should know if they have any open streams but they would have a hard time telling what else they are missing from not calling exit(). There may be profiling cleanup (profiling won't work right for the child?) and other magic destructors. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100316021240.N24765>