Re: [Chicken-users] Updated README
From: Alaric Snell-Pym Subject: [Chicken-users] Updated README Date: Fri, 02 Sep 2011 14:00:59 +0100 > > Now that the bootstrap binaries at code.call-cc.org/bootstrap are > deprecated, and having stubbed my toe once too many times on building > git versions of chicken, I'd like to suggest the attached patch to the > build advice in README. Thanks. Patch is applied. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Fwd: Re: process-wait
On Sep 3 2011, Alan Post wrote: but it is important to me to be able to wait for children I spawn and collect their exit status--this is a feature I use and need to retain. If the runtime is going to change the way that this works, I still need the ability to check the status of my child processes, and not to have that all automatically done. Rest assured! As long as I take the pain, there is no default like "spawn and forget". At worst something alike might be the default on exit. However my euphoria from the last messages is gone anyway. Please take my previous utterances seriously if you do use signals and like to help. But the current state of affairs is not as great as it appeared to be after testing on two machines (an IA64 laptop and an Sheeva Plug) but both behind the same network link. In the meantime I tried to deploy the very same thing on two IA64 virtual machines with full networks connections. And what can I say: it's not working well. Full load appears to be fine, but signals get lost when load is too low. As it seems to be. But: I made a mistake anyway: I have this get-rid-of-pid function, which by it's name means: "do what I mean"; and sure it does not. Hence I'm unsure where my bug actually lives. /Jerry ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Fwd: Re: process-wait
On Sat, Sep 03, 2011 at 10:30:24AM -0400, John Cowan wrote: > Jörg F. Wittenberger scripsit: > > > But wait: Jules is right: somehow there needs to be some arrangement > > that there's a waitpid sure before the process exists on any other way > > to prevent zombies on the system. > > > > Does anyone have a suggestion how to assure that? > > If the parent process calls sigaction() on SIGCHLD and set the sa_handler > to SIG_DFL and the sa_flags to SA_NOCLDWAIT, then its children will not > become zombies, but will just vanish. See > http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigaction.html > I don't understand some of the details regarding the Chicken Scheduler as it is being talked about in this thread, so please excuse me if I demonstrate that ignorance here, but it is important to me to be able to wait for children I spawn and collect their exit status--this is a feature I use and need to retain. If the runtime is going to change the way that this works, I still need the ability to check the status of my child processes, and not to have that all automatically done. -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Fwd: Re: process-wait
Jörg F. Wittenberger scripsit: > But wait: Jules is right: somehow there needs to be some arrangement > that there's a waitpid sure before the process exists on any other way > to prevent zombies on the system. > > Does anyone have a suggestion how to assure that? If the parent process calls sigaction() on SIGCHLD and set the sa_handler to SIG_DFL and the sa_flags to SA_NOCLDWAIT, then its children will not become zombies, but will just vanish. See http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigaction.html -- La mayyitan ma qadirun yatabaqqa sarmadiJohn Cowan Fa idha yaji' al-shudhdhadh fa-l-maut qad yantahi. co...@ccil.org --Abdullah al-Hazred, Al-`Azif http://www.ccil.org/~cowan ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Fwd: Re: process-wait
On Sep 2 2011, Jörg F. Wittenberger wrote: 3. It might be all much easier to rearrange cicken different way to allow "real" code in signal handlers. (mutex-unlock! is already proven to be "real code" in that case, i.e., *will* hang eventually.) ... This one does not try to handle POSIX signals in the original signal handler. Instead the handlers are activated from ##sys#schedule. It occurred to me that with my modifications (especially invoking the signal handler code from ##sys#schedule) it would no longer be required to call C_raise_interrupt in the global_signal_handler at all. I tried: it sill works - and so much better than before. Furthermore with this change to deal with child processes: just have a thread waiting for the process to terminate (then process-wait-for-pid case). It will not block but see the process dying. I guess I should clean up the code. But wait: Jules is right: somehow there needs to be some arrangement that there's a waitpid sure before the process exists on any other way to prevent zombies on the system. Does anyone have a suggestion how to assure that? Explicit termination would require knowledge about all processes started so far (which have not been waited for). This in turn would require more changes to the posix unit (either maintain a list with process-fork or even use a structure as process reference instead of the raw pid. Both not too nice. I'd rather knew about some posix magic I'm not aware off. Does it exist? Best regards /Jörg . ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
