Date: Thu, 9 Dec 1999 15:30:42 -0600 From: "Richard Seaman, Jr." <dick@tar.com> To: Jason Evans <jasone@canonware.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Possible libc changes to support LinuxThreads Message-ID: <19991209153042.C782@tar.com> In-Reply-To: <19991209125745.G73529@sturm.canonware.com> References: <19991209003517.E73529@sturm.canonware.com> <19991209064256.B34152@tar.com> <19991209125745.G73529@sturm.canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 09, 1999 at 12:57:45PM -0800, Jason Evans wrote: > On Thu, Dec 09, 1999 at 06:42:56AM -0600, Richard Seaman, Jr. wrote: > > On Thu, Dec 09, 1999 at 12:35:17AM -0800, Jason Evans wrote: > > > > The problem with cancellation points, libc and linuxthreads has been > > that you need to wade through libc and replace instances of, for > > example, write() with either _write() or _libc_write() in order to > > avoid propagating cancellation points where they don't belong. > > Now I understand why you claimed that making cancellation work is a lot of > work. Since that isn't currently done, do you think it would be better to > leave broken cancellation in the LinuxThreads port, or to take it out? As > things stand right now, "broken" means: > > 1) Not all mandatory cancellation points are implemented. > 2) Some functions may act as cancellation points, even though they > shouldn't. > > We can fix 1) with some symbol munging, but 2) is much more difficult, as > you point out. I think #2 above is very dangerous, since you can get a cancellation point unexpectedly while the thread holds resources (eg a lock). If you cancel while holding a lock, you could deadlock. This could even happen within libc, where (for example) fread puts a lock around the read syscall. If read is a cancellation point, the libc lock for the FILE pointer won't get released (at least I don't think it will). A user app could have the same problem if there are unexpected cancellation points. The original linuxthreads port left the cancellation functions in, but didn't do any syscall wrapping to implement libc cancellation points. A user app can create cancellation points with pthread_test_cancel(), which helps a little, but he doesn't get the POSIX libc cancellation points. 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? -- 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?19991209153042.C782>