------=_Part_1919_840700718.1465099274714
Content-Type: multipart/alternative;
 boundary="----=_Part_1920_1144111358.1465099274714"

------=_Part_1920_1144111358.1465099274714
Content-Type: text/plain; charset=UTF-8

I think the paper is right that this is dangerous.

I sitll find having a joining_thread compelling anyway.


What are the alternative solutions for a joining_thread?

1. Make code that will not throw in threads?
2. try { } catch (...) before joining in the joining_thread destructor?

Any other ideas?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f6d55e4a-b370-48a4-b688-fe89aa510b93%40isocpp.org.

------=_Part_1920_1144111358.1465099274714
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think the paper is right that this is dangerous.<div><br=
></div><div>I sitll find having a joining_thread compelling anyway.</div><d=
iv><br></div><div><br></div><div>What are the alternative solutions for a j=
oining_thread?</div><div><br></div><div>1. Make code that will not throw in=
 threads?</div><div>2. try { } catch (...) before joining in the joining_th=
read destructor?</div><div><br></div><div>Any other ideas?</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f6d55e4a-b370-48a4-b688-fe89aa510b93%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f6d55e4a-b370-48a4-b688-fe89aa510b93=
%40isocpp.org</a>.<br />

------=_Part_1920_1144111358.1465099274714--

------=_Part_1919_840700718.1465099274714--

.

On 5 June 2016 at 07:01, Germ=C3=A1n Diago <germandiago@gmail.com> wrote:
> I think the paper is right that this is dangerous.

The paper is saying that joining_thread is not panacea. I agree with
that, but I don't agree that
we shouldn't provide a tool for the cases where joining at scope exit
is desired.

>
> I sitll find having a joining_thread compelling anyway.
>
>
> What are the alternative solutions for a joining_thread?
>
> 1. Make code that will not throw in threads?

What does that mean? Also, RAII is not just about throwing, any scope
exit will cause the problem
that joining_thread is designed to solve.

> 2. try { } catch (...) before joining in the joining_thread destructor?

How would that help?

The current alternative is to use a custom RAII handle. There are many of t=
hose.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUbKnbAGrvtBmxa-0CDy-B3ZHhwSHtUP_4%3D10Kdyz=
LviDg%40mail.gmail.com.

.

------=_Part_4436_750260549.1465275091699
Content-Type: multipart/alternative;
 boundary="----=_Part_4437_763213270.1465275091699"

------=_Part_4437_763213270.1465275091699
Content-Type: text/plain; charset=UTF-8



> What does that mean? Also, RAII is not just about throwing, any scope
> exit will cause the problem
> that joining_thread is designed to solve.
>

You will have to agree that you can expect a lot of the time an exception
thrown
but that calling exit(-1) in the middle of a function is not good
practice...



> > 2. try { } catch (...) before joining in the joining_thread destructor?
>
> How would that help?
>
>
It is usually the case that functions can throw exceptions, so this would
handle the usual case.
I do not find common or a good practice to use exit or similar in the
middle of functions.

I think that a try catch clause would make it much safer. If you want
something more primitive,
just wrap the thread, do not use joining_thread. If you want a thread that
*just* joins without catching
exceptions, you could also do your own wrappers. Or maybe policies should
be set or something.

I agree with the paper that this is not safe enough for the common usage.


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e691df26-219e-4694-be1f-a3a0a21af2c3%40isocpp.org.

------=_Part_4437_763213270.1465275091699
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">What does=
 that mean? Also, RAII is not just about throwing, any scope
<br>exit will cause the problem
<br>that joining_thread is designed to solve.
<br></blockquote><div><br>You will have to agree that you can expect a lot =
of the time an exception thrown<br>but that calling exit(-1) in the middle =
of a function is not good practice...<br>=C2=A0<br></div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">&gt; 2. try { } catch (...) bef=
ore joining in the joining_thread destructor?
<br>
<br>How would that help?
<br>
<br></blockquote><div><br>It is usually the case that functions can throw e=
xceptions, so this would handle the usual case.<br>I do not find common or =
a good practice to use exit or similar in the middle of functions.<br><br>I=
 think that a try catch clause would make it much safer. If you want someth=
ing more primitive, <br>just wrap the thread, do not use joining_thread. If=
 you want a thread that *just* joins without catching<br>exceptions, you co=
uld also do your own wrappers. Or maybe policies should be set or something=
..<br><br>I agree with the paper that this is not safe enough for the common=
 usage.<br><br><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e691df26-219e-4694-be1f-a3a0a21af2c3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e691df26-219e-4694-be1f-a3a0a21af2c3=
%40isocpp.org</a>.<br />

------=_Part_4437_763213270.1465275091699--

------=_Part_4436_750260549.1465275091699--

.

On 7 June 2016 at 07:51, Germ=C3=A1n Diago <germandiago@gmail.com> wrote:
>
>> What does that mean? Also, RAII is not just about throwing, any scope
>> exit will cause the problem
>> that joining_thread is designed to solve.
>
>
> You will have to agree that you can expect a lot of the time an exception
> thrown
> but that calling exit(-1) in the middle of a function is not good
> practice...

I'm not talking about calling std::exit. I'm talking about return,
break, continue and goto. What
does std::exit have to do with any of this?

>> > 2. try { } catch (...) before joining in the joining_thread destructor=
?
>>
>> How would that help?
>>
>
> It is usually the case that functions can throw exceptions, so this would
> handle the usual case.

It doesn't handle return, break, continue or goto.

> I think that a try catch clause would make it much safer. If you want
> something more primitive,
> just wrap the thread, do not use joining_thread. If you want a thread tha=
t

"Just wrap the thread"? With what? joining_thread, perhaps?

> *just* joins without catching
> exceptions, you could also do your own wrappers.

We already have "our own wrappers", and we have too many of them. None
of them ship
with an implementation. Hence the proposal to add such a wrapper to
the standard.

> I agree with the paper that this is not safe enough for the common usage.

The common usage that joining_thread is for is the usage where the
thread is intended to
be joined at scope exit. There are plenty of third-party types to do
exactly that. joining_thread
is safe for the cases it's designed for, and it's much safer than
risking terminate() for those cases.
Those cases have been found to be common enough to warrant a standard
facility (arguably,
of course).

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUbVxGoECR_xtUQPD05_idOm%3DKa%2BrXHX-xCO5sk=
CnCa03g%40mail.gmail.com.

.