Date: Thu, 9 Dec 1999 16:48:54 -0600 From: "Richard Seaman, Jr." <dick@tar.com> To: Daniel Eischen <eischen@vigrid.com> Cc: dick@tar.com, jasone@canonware.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Possible libc changes to support LinuxThreads Message-ID: <19991209164854.E782@tar.com> In-Reply-To: <199912092241.RAA19312@pcnet1.pcnet.com> References: <199912092241.RAA19312@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 09, 1999 at 05:41:09PM -0500, Daniel Eischen wrote: > 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. Hmm.. What happens with (for example) fread() ? fread, in the thread safe version, can be: lock FILE pointer read unlock FILE pointer If fread is a cancellation point, don't you end up with the lock held still? Or, I guess since you keep track of lock owners you can unwind the locks if the thread cancels? -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991209164854.E782>