From owner-freebsd-hackers Thu Dec 9 14:41:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id B3F0A15097 for ; Thu, 9 Dec 1999 14:41:12 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id RAA19312; Thu, 9 Dec 1999 17:41:09 -0500 (EST) Date: Thu, 9 Dec 1999 17:41:09 -0500 (EST) From: Daniel Eischen Message-Id: <199912092241.RAA19312@pcnet1.pcnet.com> To: dick@tar.com, jasone@canonware.com Subject: Re: Possible libc changes to support LinuxThreads Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Richard Seaman, Jr. wrote: > Actually, I don't think all that many apps use pthread_cancel(). > Its kind of messy to use. Most can get along without it, which > is why there have only been a limited number of complaints about > the lack of pthread_cancel() in libc_r (until recently). BTW, > I haven't looked at libc_r's new cancellation functions. How do > they avoid propagating cancellation points in libc without > changing libc? Maybe they have an idea that can be used here? Hi Richard, Libc_r doesn't avoid propagating cancellation points. A read() from within a libc(_r) function will still be a cancellation point. We had to weigh the lack of having pthread_cancel() versus having pthread_cancel() with non-standard cancellation points. In the end, only those applications that use pthread_cancel() are affected. I think the number of complaints saying "Hey, pthread_cancel support has non-standard cancellation points" will be less than the number of complaints because we don't have _any_ pthread_cancel support. Well, that's what I hope anyways ;-) Time will probably prove me wrong... Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message