$include_dir="/home/hyper-archives/boost/include";
include("$include_dir/msg-header.inc")
?>
- Next message: Johan Nilsson: "Re: [boost] Boost.Threads, N2178, N2184, et al"
- Previous message: Martin Schulz: "Re: [boost] [Review] Quantitative Units library review begins today March 26"
- In reply to: David Abrahams: "Re: [boost] Boost.Threads, N2178, N2184, et al"
- Next in thread: Anthony Williams: "Re: [boost] Boost.Threads, N2178, N2184, et al"
- Reply: Anthony Williams: "Re: [boost] Boost.Threads, N2178, N2184, et al"
- Reply: David Abrahams: "Re: [boost] Boost.Threads, N2178, N2184, et al"
David Abrahams wrote:
> I suggest that trying to use meanings of "cancellation" other than the
> one(s) used in the pthread standard at this point can only confuse
> things, which hardly seems like a way to un-stall the process.
I might be completely wrong, but doesn't the pthread standard
require a thread to stop once it has been cancelled?
The thread may decide to defer the request, but not to deny.
Correct?
So what we are discussing (and what I want to suggest too) is
to let the thread decide if it honours the cancellation request.
My point was just to give it a different name then, since this
basically is a communication channel that can be used for
other purposes too.
Regards,
Roland
- Next message: Johan Nilsson: "Re: [boost] Boost.Threads, N2178, N2184, et al"
- Previous message: Martin Schulz: "Re: [boost] [Review] Quantitative Units library review begins today March 26"
- In reply to: David Abrahams: "Re: [boost] Boost.Threads, N2178, N2184, et al"
- Next in thread: Anthony Williams: "Re: [boost] Boost.Threads, N2178, N2184, et al"
- Reply: Anthony Williams: "Re: [boost] Boost.Threads, N2178, N2184, et al"
- Reply: David Abrahams: "Re: [boost] Boost.Threads, N2178, N2184, et al"
$include_dir="/home/hyper-archives/boost/include";
include("$include_dir/msg-footer.inc");
?>