Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 26969 invoked by uid 6000); 12 Mar 1999 17:59:38 -0000 Received: (qmail 26826 invoked from network); 12 Mar 1999 17:59:32 -0000 Received: from twinlark.arctic.org (204.107.140.52) by taz.hyperreal.org with SMTP; 12 Mar 1999 17:59:32 -0000 Received: (qmail 6306 invoked by uid 500); 12 Mar 1999 17:59:09 -0000 Date: Fri, 12 Mar 1999 09:59:09 -0800 (PST) From: Dean Gaudet To: new-httpd@apache.org Subject: Re: Apache Week issue 153 (12th March 1999) In-Reply-To: Message-ID: X-Comment: Visit http://www.arctic.org/~dgaudet/legal for information regarding copyright and disclaimer. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org On Fri, 12 Mar 1999, Apache Week wrote: > Modules will be allowed to use SIGPIPE > > The current version of Apache traps the SIGPIPE signal to see if the > connection to the client (browser) has been lost. However this means > that Apache modules cannot use SIGPIPE if they have outgoing > connections to, say, a database or other remote system. The core of > Apache has been updated now so that it does not use or trap SIGPIPE at > all. Instead, all functions which write to or read from the client > check their error status and if the connection is lost they set the > "aborted" field in the connection data structure. > > This will allow modules to trap SIGPIPE so that they can monitor their > own connection. Modules can also check for a lost connection more > easily, by looking at the aborted field. This isn't quite the whole story -- modules are allowed to trap it while they're doing their own socket work, but they must immediately restore it before returning to the core or calling another module. Anything else is a broken module. Along with that fd check I mentioned a while back, a signal handler check would be a useful debugging option. Dean