[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]
Greg A. Woods woods@weird.com
Tue, 28 May 2002 15:10:59 -0700 (PDT)
[ On Sunday, May 26, 2002 at 00:10:06 (-0700), Bryan Stansell wrote: ] > Subject: Re: conserver eventually goes catatonic after SIGPIPE (on NetBSD) > > right...no SIGPIPE handler. but, there is a SIGCHLD handler, which > gets called when forked processes die. i don't think this is a problem > (yet, at least). Conserver definitely needs a SIGPIPE handler -- unless it wants to die unexpectedly every time it writes to a client that has disconnected abnormally. The kernel sends SIGPIPE to processes writing to closed sockets just as it does to processes writing to closed pipes.... > looking at #2, you see it's calling waitpid() from ConsChat(). > ConsChat() is part of your patch. the problem, i'm guessing, is that > the waitpid() inside the while loop has a little bad logic. Bummer. I completely missed/ignored the SIGCHLD handler and its call to waitpid() when I added mine, and then when I read the stack backtrace I completely forgot about mine -- or rather I think I assumed that since it waited explicitly for the just-forked chat pid there could be no confusion. I've been looking at some way to fix this. The ideal fix would be to block SIGCHLD during the execution of the chat program. However the code currently supports systems without sigaction(2). Is that important? I'll bet conserver won't even compile on systems without sigaction() despite the fact that API alone is handled portably.... The alternative is to keep a list of chat child PIDs and walk through them after SIGCHLD is caught too.... That's a bit more work, but still easily doable (I've got similar code already tested and working for some other applications). It seems a little messier since it introduces concurrency in the error handling for chat processes where they're currently really more synchronous.... -- Greg A. Woods +1 416 218-0098; <gwoods@acm.org>; <g.a.woods@ieee.org>; <woods@robohack.ca> Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>