From owner-freebsd-hackers Wed Dec 2 06:09:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA25555 for freebsd-hackers-outgoing; Wed, 2 Dec 1998 06:09:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.tar.com (ns.tar.com [204.95.187.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA25546 for ; Wed, 2 Dec 1998 06:09:56 -0800 (PST) (envelope-from lists@tar.com) Received: from ppro.tar.com (ppro.tar.com [204.95.187.9]) by ns.tar.com (8.9.1/8.9.1) with SMTP id IAA03962; Wed, 2 Dec 1998 08:09:12 -0600 (CST) (envelope-from lists@tar.com) Message-Id: <199812021409.IAA03962@ns.tar.com> From: "Richard Seaman, Jr." To: "John Birrell" , "The Hermit Hacker" Cc: "freebsd-hackers@FreeBSD.ORG" Date: Wed, 02 Dec 98 08:09:12 -0600 Reply-To: "Richard Seaman, Jr." X-Mailer: PMMail 1.92 For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: pthread_cancel() function... Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 2 Dec 1998 13:05:08 +1100 (EST), John Birrell wrote: >The Hermit Hacker wrote: >> The closest I can find is pthread_detach(), but according to the man page for pthread_cancel under Solaris, tehy aren't quite the same... >> >> Anyone with experience with this that can comment? > >pthread_cancel() requires tests at each of the cancellation points in >the functions that the standard nominates. > >Every time I implement something like this, I suffer from the mail sent >to me by developers who say "there's no bugs in my code and it works on >such-n-such, so your code is broken". The use of pthread_cancel() in an >application often causes resource locking problems (or rather, problems >with resources not being unlocked before the thread is killed). It is >an optional part of the standard, which sort-of implies that applications >shouldn't _require_ it. Are you sure it's not optional in your application? I was under the impression that pthread_cancel was a manditory, not optional, part of both the POSIX and SS2 specifications. However, I agree it causes problems when used improperly, and it sure seems like implementing it is a royal pain in the you know what. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message