Date: Tue, 4 Dec 2001 02:18:15 -0600 From: Alfred Perlstein <bright@mu.org> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: Louis-Philippe Gagnon <louisphilippe@macadamian.com>, freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Possible libc_r pthread bug Message-ID: <20011204021815.E92148@elvis.mu.org> In-Reply-To: <Pine.SUN.3.91.1011130170847.14642A-100000@pcnet1.pcnet.com>; from eischen@pcnet1.pcnet.com on Fri, Nov 30, 2001 at 05:15:50PM -0500 References: <094601c179ea$7cca85c0$2964a8c0@MACADAMIAN.com> <Pine.SUN.3.91.1011130170847.14642A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Daniel Eischen <eischen@pcnet1.pcnet.com> [011130 16:17] wrote:
> On Fri, 30 Nov 2001, Louis-Philippe Gagnon wrote:
> > If at first you don't succeed...
> >
> > I've encountered a problem using pthread_cancel, pthread_join and
> > pthread_setcanceltype, I'm hoping someone can shed some light.
> >
> > (in a nutshell : pthread_setcanceltype doesn't seem to work in FreeBSD 4.4)
> >
> > (posted to -current and -hackers; if there's a more appropriate mailing list
> > for this, please let me know)
> >
> > I recently encountered a situation where, after calling pthread_cancel to
> > cancel a thread, the call to pthread_join hangs indefinitely. I quickly figured
> > out that it was because the thread being cancelled was never reaching a
> > cancellation point (in fact it was an infinite loop with no function calls at all).
> > Sure enough, adding a pthread_testcancel() in the loop allowed
> > pthread_join to return. However this solution isn't acceptable for my requirements.
please test the following patch:
Index: uthread/uthread_kern.c
===================================================================
RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_kern.c,v
retrieving revision 1.39
diff -u -r1.39 uthread_kern.c
--- uthread/uthread_kern.c 7 Oct 2001 02:34:43 -0000 1.39
+++ uthread/uthread_kern.c 4 Dec 2001 08:22:22 -0000
@@ -579,6 +579,18 @@
curthread);
}
/*
+ * If the currently running thread is a user thread,
+ * test for async cancel:
+ */
+ if ((curthread->flags & PTHREAD_FLAGS_PRIVATE) == 0) {
+ int cfl = curthread->cancelflags;
+
+ cfl &= (PTHREAD_CANCEL_ASYNCHRONOUS|
+ PTHREAD_AT_CANCEL_POINT);
+ if (cfl != 0)
+ pthread_testcancel();
+ }
+ /*
* Continue the thread at its current frame:
*/
switch(curthread->ctxtype) {
@@ -1078,6 +1090,8 @@
curthread->sig_defer_count--;
}
else if (curthread->sig_defer_count == 1) {
+ int cfl;
+
/* Reenable signals: */
curthread->sig_defer_count = 0;
@@ -1091,8 +1105,9 @@
* Check for asynchronous cancellation before delivering any
* pending signals:
*/
- if (((curthread->cancelflags & PTHREAD_AT_CANCEL_POINT) == 0) &&
- ((curthread->cancelflags & PTHREAD_CANCEL_ASYNCHRONOUS) != 0))
+ cfl = curthread->cancelflags;
+ cfl &= (PTHREAD_CANCEL_ASYNCHRONOUS|PTHREAD_AT_CANCEL_POINT);
+ if (cfl != 0)
pthread_testcancel();
/*
--
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
http://www.morons.org/rants/gpl-harmful.php3
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?20011204021815.E92148>