svn commit: r205165 - head/lib/libc/gen

Bruce Evans brde at optusnet.com.au
Mon Mar 15 15:40:54 UTC 2010


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


More information about the svn-src-head mailing list