From owner-freebsd-current@FreeBSD.ORG  Tue Aug  2 14:10:20 2005
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
X-Original-To: current@freebsd.org
Delivered-To: freebsd-current@FreeBSD.ORG
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id E18CA16A42A
	for <current@freebsd.org>; Tue,  2 Aug 2005 14:10:20 +0000 (GMT)
	(envelope-from deischen@freebsd.org)
Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10])
	by mx1.FreeBSD.org (Postfix) with ESMTP id EE8F543D6B
	for <current@freebsd.org>; Tue,  2 Aug 2005 14:10:15 +0000 (GMT)
	(envelope-from deischen@freebsd.org)
Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11])
	by mail.ntplx.net (8.13.4/8.13.4/NETPLEX) with ESMTP id j72EAFYS028622; 
	Tue, 2 Aug 2005 10:10:15 -0400 (EDT)
Date: Tue, 2 Aug 2005 10:10:14 -0400 (EDT)
From: Daniel Eischen <deischen@freebsd.org>
X-X-Sender: eischen@sea.ntplx.net
To: Poul-Henning Kamp <phk@haven.freebsd.dk>
In-Reply-To: <Pine.GSO.4.43.0508020954480.5408-100000@sea.ntplx.net>
Message-ID: <Pine.GSO.4.43.0508021007350.5408-100000@sea.ntplx.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net)
Cc: current@freebsd.org
Subject: Re: pthreads: shouldn't nanosleep() be a cancellation point ?
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Daniel Eischen <deischen@freebsd.org>
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2005 14:10:21 -0000

On Tue, 2 Aug 2005, Daniel Eischen wrote:

> On Tue, 2 Aug 2005, Poul-Henning Kamp wrote:
>
> >
> > Since sleep() is a cancellation point, shouldn't nanosleep() be as well ?
>
> nanosleep() is a cancellation point.  At least, that's the way it's
> coded and should work.  Note that _nanosleep() isn't.  By design, if
> libc is using _nanosleep() in places, then that wouldn't cause a
> cancellation point.
>
> > (this would also cover usleep())
>
> Hmm, is your real complaint that usleep() is not a cancellation point?
> usleep() should be a cancellation point, so you can fix it if you
> want (s/_nano/nano/ and remove the namespace stuff).

Hmm, the same could be said for sleep() in libc also, but we jump
through hoops to allow the thread libraries override sleep() with
their own cancellable version.  I think this is in case libc wants
to use sleep(), usleep(), nanosleep() internally and not introduce
cancellation points into functions that shouldn't have them.

-- 
DE