From owner-freebsd-questions Mon Mar 24 19:54: 5 2003 Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A27637B401 for ; Mon, 24 Mar 2003 19:54:03 -0800 (PST) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83AB843F85 for ; Mon, 24 Mar 2003 19:54:02 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.7/8.12.7) id h2P3s1gx037795; Mon, 24 Mar 2003 21:54:01 -0600 (CST) (envelope-from dan) Date: Mon, 24 Mar 2003 21:54:01 -0600 From: Dan Nelson To: Dave Hayes Cc: freebsd-questions@FreeBSD.ORG Subject: Re: SIGPIPE and threaded servers Message-ID: <20030325035401.GB22424@dan.emsphone.com> References: <200303250235.h2P2Zuuq056175@hokkshideh2.jetcafe.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303250235.h2P2Zuuq056175@hokkshideh2.jetcafe.org> X-OS: FreeBSD 5.0-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-26.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In the last episode (Mar 24), Dave Hayes said: > Dan Nelson writes: > > In the last episode (Mar 23), Dave Hayes said: > > > I have a relatively simple threaded TCP server that services high > > > volumes of requests. Currently it appears to randomly crash > > > receiving a SIGPIPE. > > But it's not doing what I want it to do. > > I don't want my process with all it's threads to terminate if I write > on a pipe with no reader. I want the write() to return EPIPE so I can > handle it there. It's not doing that currently. Installing a signal > handler doesn't work to get it to do that. Ignoring the signal > doesn't work. I've used both signal() and sigaction() semantics to no > avail. So what you're saying is that even if you ignore SIGPIPE, your process still dies with SIGPIPE? That definitely should not happen, and probably counts as a kernel bug (signal is not wrapped by libc_r so threads shouldn't affect anything). -- Dan Nelson dnelson@allantgroup.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message