Re: sys_fork

If you're going to use signals (a good idea), you should get a good book,  
like
Stevens or Robbins & Robbins. The signal coverage in Robbins & Robbins
is more up to date than the orginial Stevens. I haven't seen the second  
edition
of Stevens, but the descriptions say that signal coverage has been  
expanded.


On Tue, 29 Nov 2005 16:20:13 -0800, Ricardo Nabinger Sanchez  
<[email protected]> wrote:

> Quoting  HIToC <[email protected]>
> Sent on  Tue, 29 Nov 2005 19:59:56 +0100
>
> Hello,
>
> I wouldn't recommend you to call wait4pid, because your process (the  
> accept
> () one) will block, and thus fork() will not be an advantage (you can do
> that naturally without forking).
>
> What would be a nice thing to do is to prepare a signal handler for
> SIG_CHILD, to clean up its children.  It is very single to use, all you
> need is to tell the kernel to use your custom function for handling
> SIG_CHILD, instead of the default action (which is to ignore the signal,
> and you'll end with a bunch of zombies).
>
> Btw, such a function is like this in C:
>
> void handle_sigchild() {
> 	wait();
> }
>
> notice that the process will not block, as the signal is being delivered
> because of a terminating child.  it will be cleaned even if the process  
> is
> blocked in accept().
>
> I'm almost sure that you'll also need to handle interrupted accept(),  
> which
> will return -1 and errno will have EINTR (interrupted system call).  in
> this case, call accept() again :)
>
> have fun :)
>