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
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Reply via email to