Date: Tue, 2 Aug 2005 10:10:14 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Poul-Henning Kamp <phk@haven.freebsd.dk> Cc: current@freebsd.org Subject: Re: pthreads: shouldn't nanosleep() be a cancellation point ? Message-ID: <Pine.GSO.4.43.0508021007350.5408-100000@sea.ntplx.net> In-Reply-To: <Pine.GSO.4.43.0508020954480.5408-100000@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0508021007350.5408-100000>