Received: by taz.hyperreal.com (8.6.12/8.6.5) id LAA14737; Tue, 23 Jan 1996 11:57:41 -0800 Received: from neog.com by taz.hyperreal.com (8.6.12/8.6.5) with ESMTP id LAA14725; Tue, 23 Jan 1996 11:57:39 -0800 Received: (from nschrenk@localhost) by neog.com (8.6.12/8.6.9) id OAA27058; Tue, 23 Jan 1996 14:04:40 -0600 Date: Tue, 23 Jan 1996 14:04:40 -0600 (CST) From: Nathan Schrenk To: new-httpd@hyperreal.com Subject: Re: Timeout patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-new-httpd@apache.org Precedence: bulk Reply-To: new-httpd@hyperreal.com On Tue, 23 Jan 1996, David Robinson wrote: [code removed] > Hmm, isn't there a race condition here? What happens if it times out just > after sucessful fwrite, but before the alarm call? Bad things would happen when the connection was aborted in the timout() signal handler and then control returned to send_fd(). > I think this may be better solved with a reset_timeout() routine inside > http_main.c which could deal with any race conditions. This reset_timeout() routine is a good idea, and will eliminate the need for timeout_name being a global. When I get a minute, I will rewrite the patch and resubmit it. Any suggestions on safeguarding reset_timeout() against a similar race condition? Perhaps block_alarms()/unblock_alarms() should be stuck around the alarm resetting code? Nathan > David. -- Nathan Schrenk nschrenk@neog.com Neoglyphics Media Corp. http://www.neog.com/