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.
> I discovered the pthread_setcanceltype function and its 
> PTHREAD_CANCEL_ASYNCHRONOUS parameter, which looked like 
> they would give me exactly what I needed : allow threads to be cancelled 
> regardless of what they are doing (basically a pthread equivalent to 
> TerminateThread).
> Unfortunately, my tests have been less than conclusive : pthread_setcanceltype
> doesn't seem to do anything at all. It tells me it succeeds, subsequent calls 
> properly report the previous cancellation type as ASYNCHRONOUS. 
> But pthread_join still hangs, and adding pthread_testcancel calls still 
> makes it work...
> I'm working on a FreeBSD 4.4-release machine; I ran the same test under 
> FreeBSD 4.3-release and got the same results. However, running it on a 
> Linux box (Mandrake release, 2.4.x kernel), I get exactly the results I 
> was expecting (that is, setting the cancellation type to asynchronous allows
> the thread to be cancelled at any time)
> see the end of this message for my test program
> So the questions are
> -am I doing something wrong or misinterpreting the man pages?

No, not really.

> -if not, is this a known bug?

Or feature?

> -if so, is there a workaround (or is it already fixed)?

Not fixed.  Work-around could be to use pthread_signal and
exit the thread from there.

> -if not, can someone investigate? (I once had a look at the libc_r code 
>  and ran away screaming)

Since your thread is compute bound, it is only woken up from the
thread library's scheduling signal handler.  In this case, it can
only resume the thread from the interrupted context, and so there
is no check for the thread being canceled.

Dan Eischen

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to