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
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
