From owner-cvs-lib  Sat May 17 23:54:13 1997
Return-Path: <owner-cvs-lib>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id XAA14277
          for cvs-lib-outgoing; Sat, 17 May 1997 23:54:13 -0700 (PDT)
Received: from spinner.DIALix.COM (spinner.dialix.com [192.203.228.67])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA14265;
          Sat, 17 May 1997 23:53:51 -0700 (PDT)
Received: from spinner.DIALix.COM (localhost.dialix.com.au [127.0.0.1])
          by spinner.DIALix.COM with ESMTP id OAA04790;
          Sun, 18 May 1997 14:52:54 +0800 (WST)
Message-Id: <199705180652.OAA04790@spinner.DIALix.COM>
X-Mailer: exmh version 2.0gamma 1/27/96
To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru>
cc: Bruce Evans <bde@zeta.org.au>, peter@FreeBSD.ORG, cvs-all@FreeBSD.ORG,
        cvs-committers@FreeBSD.ORG, cvs-lib@FreeBSD.ORG
Subject: Re: cvs commit: src/lib/libc/gen sleep.c 
In-reply-to: Your message of "Sun, 18 May 1997 10:39:14 +0400."
             <Pine.BSF.3.96.970518102602.566C-100000@nagual.pp.ru> 
Date: Sun, 18 May 1997 14:52:53 +0800
From: Peter Wemm <peter@spinner.DIALix.COM>
Sender: owner-cvs-lib@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= wrote:

> But it is not the only difference. As I say, old sleep restarted again
> after signal != SIGALRM (f.e. SIGCHLD), but new sleep terminates! I
> suspect this thing break Apache. 

Apache doesn't fail with non-BSD systems that sleep doesn't restart after 
non-ALRM signals, eg: sunos, solaris, hpux, digital unix, etc..

Apache doesn't use signals internally other than SIGALRM anyway.  (well, 
the user can send SIGHUP and SIGTERM, but that's an exception, not the 
normal case during operation)

eg: from Digital Unix:
  If the sleep() function returns because the requested time has elapsed, it
  returns 0 (zero).  If the sleep() function returns because it caught a
  signal, the function returns the number of seconds remaining in the suspen-
  sion.

I noticed that apache is having a lot of trouble with fin_wait_2 when using
keepalive connections to unix netscape3 and doesn't run very well with -X
when large files are transferred (more than socket buffer I suspect).  
I found a mention of this in the docs where it explicitly listed Netscape 
on FreeBSD as one known rogues that don't do client keepalive properly.

Cheers,
-Peter