Re: [boost] [thread] terminating destructor

Subject: Re: [boost] [thread] terminating destructor
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-10-25 13:18:28

Le 25/10/12 10:42, Andrzej Krzemienski a écrit :
> 2012/10/25 Olaf van der Spek <ml_at_[hidden]>
>
>> On Thu, Oct 25, 2012 at 10:11 AM, Andrzej Krzemienski
>> <akrzemi1_at_[hidden]> wrote:
>>> 2012/10/25 Olaf van der Spek <ml_at_[hidden]>
>>>
>>>> On Thu, Oct 25, 2012 at 9:56 AM, Andrzej Krzemienski <
>> akrzemi1_at_[hidden]>
>>>> wrote:
>>>>
>>>> According to my (limited) understanding of the standard: no. Because, as
>>>> per requirement in Sect 30.6.8 paragraph 5, the "launched" thread
>>>> completion must synchronize with (happen before) the last function that
>>>> releases the shared state.
>>>>
>>>> If the launched thread finishes before the release, the thread cannot
>>>> perform this release.
>> But why? What's the rationale for this requirement?
>> Is it the same rationale as the thread destructor of a non-detached
>> thread terminating (for safety)?
>
> Basically, as with the thread's destructor: you have to do something: join,
> detach, signal run-time error. Your preference is clearly to detach. I
> could only found this document:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2802.html
> That gives some rationale against the detachment.
>
> My guess is that termination was a good choice for a low-level primitive,
> and join was a good candidate for a higher-level primitive like async.
> async (owing to the joining destructor) gives you the ability to think in
> C-style scoped manner. Or in RAII way. You exit the scope, you are done
> with the resource (thread in this case).
Yeah, I think you have explained a good reason to join.
> One may not like this async behaviour. One may write one's own
> multi-threading library using low-level threads. I guess it was the idea of
> the Kona compromise.
Would you like to create a ticket to track this issue?

Thanks a lot
Vicente