From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Robert Plantz" Subject: Re: sys_fork Date: Tue, 29 Nov 2005 20:00:21 -0800 Message-ID: References: <20051126192634.43926.qmail@web26006.mail.ukl.yahoo.com> <200511281110.51363.hitoc_mail@yahoo.it> <20051128172541.d35e0496.rnsanchez@terra.com.br> <200511291857.40019.hitoc_mail@yahoo.it> <20051129222013.305cd393.rnsanchez@terra.com.br> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <20051129222013.305cd393.rnsanchez@terra.com.br> Sender: linux-assembly-owner@vger.kernel.org List-Id: Content-Type: text/plain; format="flowed"; delsp="yes"; charset="us-ascii" To: linux-assembly@vger.kernel.org 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 wrote: > Quoting HIToC > 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 :) >