daemon design

"simplicity through a state engine"

it should be possible, if not practical to diagram the state engine of this daemon

known states makes debugging easier

the daemon must never use blocking APIs with the exception of kqueue().

just system calls if we could get away with it, but practically speaking, we need Libc for convinience

rpc/ipc for configuration and control (moves complex file parsing and unavoidable blocking file system I/O calls outside of the daemon)


dicipline issues:

all file desc. must have the non blocking bit set

all unexpected code paths must be logged

like they say in public education, "we have a zero tolerance policy towards..." functions and system calls not having their return codes checked and delt with mininumally by logging where in the program the condition occured, what the condition was, and doing appropriate clean up. Ideally, unexpected or unlikely return codes code be delt with preemptively and gracefully, for example, a fork() returning EAGAIN or ENOMEM. Those conditions are extremely unlikely in practice, but it doesn't hurt to proactively deal with those cases by saving state and trying again later. Bonus points for recovering from execve() failures.
