On Sat, 15 Apr 2017 22:50:20 +0200 marc <marc...@welz.org.za> wrote: > > Concerning the fork-parent.c and fork-parent.h revealed at > > http://welz.org.za/notes/fork-parent.tar.gz , I can't envision how > > you'd bind the fork-parent() function to the stuff your daemon > > actually does, in order to have your daemon properly fork and then > > terminate the parent when ready for business. > > > > I look at the code in fork-parent.c, and it looks to me like all the > > actual tasks of the daemon should be placed immediately above the > > child's closing p[1], so p[1] is closed when the daemon is ready. > > But in fact, fork-parent() has no interface to the real work of the > > daemon, as far as I can see. > > So fork_parent() can be seen as a minor extension of the > daemon(3) library call: In both cases after you have called it > your function is now running in the child process. The parent > process stays "stuck" in the fork_parent() or daemon() > functions. > > Note that there are "extra" close() calls in the fork_parent() > code, as after the fork() both ends of the pipe are visible > in both processes. Without closing the "other" end in each > process a read would not return EOF and the parent would stay > up even after the child has closed its end. > > Here pseudocode, commented differently: > > pipe() /* done in fork_parent */ > if(fork() > 0){ /* in fork_parent */ > close() /* in fork_parent, not the stderr of the child > */ read() /* in fork_parent */ > exit() /* in fork_parent */ > /* parent no longer exists beyond this point */ > /* this point in code, not in time */ > } > > /* here we are in the child, the parent is still running */ > /* here do all the complicated setup routes, eg */ > /* check databases, bind ports */ > ...
Wait. Are you saying that the way fork_parent() is used is to modify the source code of fork_parent() itself? If that's the case, I understand. I was under the impression that fork-parent() was a library call that you made to properly background your source code, which exists outside of function fork_parent(). And therefore I was wondering why fork_parent() didn't take a function address as an argument, and call that callback function's address where you have the elipses. > /* when everything is ready, you do: */ > > close(STDERR_FILENO); Yes. It makes sense. My question was where you put the code represented by your elipses above. Is fork_parent() a template (in the general sense, not the C++ sense) that you modify, or is it a tool you use, as is, to background code you put in a separate function? SteveT Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng