From owner-freebsd-hackers Sun Jul 6 05:57:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA21690 for hackers-outgoing; Sun, 6 Jul 1997 05:57:38 -0700 (PDT) Received: from nagual.pp.ru (ache.relcom.ru [194.58.229.133]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA21685 for ; Sun, 6 Jul 1997 05:57:33 -0700 (PDT) Received: (from ache@localhost) by nagual.pp.ru (8.8.6/8.8.5) id QAA00504; Sun, 6 Jul 1997 16:56:54 +0400 (MSD) Date: Sun, 6 Jul 1997 16:56:48 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: Peter Wemm cc: freebsd-hackers@FreeBSD.ORG Subject: sleep (was Re: Application os version compatibility?) In-Reply-To: <868192049.512817@haywire.dialix.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 6 Jul 1997, Peter Wemm wrote: > Take programs using sleep() in 3.0. If you statically link a program under > 3.0, sleep() makes a call to either the nanosleep() or signanosleep() syscall > (depending on the age of libc). If you try and run this program under 2.2 > or 2.1, it'll get a SIGSYS and die when it tries to sleep. /bin/sleep is > the primary offender. On the other hand, a dynamically linked /bin/sleep > works on both systems because both branches provide their own implementation > of sleep(3). Peter, why not remove special handling of ignored ALARMs in sleep() code? It is not compatible with world sleep() implementations and gives no advantages, but can cause potential incompatibility in future. I remember you agree with this statement too. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/