On Sat, 15 Apr 2017 22:50:20 +0200
marc <marcxdv@???> 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