Topic: Why joining_thread and no detaching_thread? Why
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 26 Apr 2016 12:24:06 +0300
Raw View
On 26 April 2016 at 11:36, Leo Heinsaar <leoheinsaar@gmail.com> wrote:
> This is more of a question first as to why it was decided to have a
> joining_thread and no detaching_thread?
Because there are plenty of users who need a joining_thread, but
apparently few users
who need a detaching_thread.
> Or some kind of a smart thread that takes a policy parameter to decide
> whether to detach or join (dj_thread? :-)) - or, for that matter, why not
That solution doesn't encode the behavior into the type system, which
would be a major
deficiency, and std::future and its users suffer from that deficiency.
I don't want to repeat that mistake.
--
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/CAFk2RUad804UA%2B-78p%3D3CJtKry1gOiLvu-K7HpNwdYjyid%3D9OA%40mail.gmail.com.
.
Author: Leo Heinsaar <leoheinsaar@gmail.com>
Date: Tue, 26 Apr 2016 02:33:19 -0700 (PDT)
Raw View
------=_Part_2942_2132808637.1461663199935
Content-Type: multipart/alternative;
boundary="----=_Part_2943_1435018319.1461663199935"
------=_Part_2943_1435018319.1461663199935
Content-Type: text/plain; charset=UTF-8
On Tuesday, April 26, 2016 at 1:24:07 PM UTC+4, Ville Voutilainen wrote:
> On 26 April 2016 at 11:36, Leo Heinsaar <leohe...@gmail.com <javascript:>>
> wrote:
> > This is more of a question first as to why it was decided to have a
> > joining_thread and no detaching_thread?
>
> Because there are plenty of users who need a joining_thread, but
> apparently few users
> who need a detaching_thread.
>
> > Or some kind of a smart thread that takes a policy parameter to decide
> > whether to detach or join (dj_thread? :-)) - or, for that matter, why
> not
>
> That solution doesn't encode the behavior into the type system, which
> would be a major
> deficiency, and std::future and its users suffer from that deficiency.
> I don't want to repeat that mistake.
>
Fair enough. Thanks Ville.
--
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/62924613-4829-405e-b2f2-d08ce9501948%40isocpp.org.
------=_Part_2943_1435018319.1461663199935
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>On Tuesday, April 26, 2016 at 1:24:07 PM UTC+4, Ville=
Voutilainen wrote:<br></div><div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">On 26 April 2016 at 11:36, Leo Heinsaar <<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"Wd50XE0MCAAJ" rel=3D"nofollow" on=
mousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"thi=
s.href=3D'javascript:';return true;">leohe...@gmail.com</a>> wro=
te:
<br>> This is more of a question first as to why it was decided to have =
a
<br>> joining_thread and no detaching_thread?
<br>
<br>Because there are plenty of users who need a joining_thread, but
<br>apparently few users
<br>who need a detaching_thread.
<br>
<br>> Or some kind of a smart thread that takes a policy parameter to de=
cide
<br>> whether to detach or join (dj_thread? :-)) - or, for that matter, =
why not
<br>
<br>That solution doesn't encode the behavior into the type system, whi=
ch
<br>would be a major
<br>deficiency, and std::future and its users suffer from that deficiency.
<br>I don't want to repeat that mistake.
<br></blockquote><div><br></div><div>Fair enough. Thanks Ville.=C2=A0</div>=
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/62924613-4829-405e-b2f2-d08ce9501948%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/62924613-4829-405e-b2f2-d08ce9501948=
%40isocpp.org</a>.<br />
------=_Part_2943_1435018319.1461663199935--
------=_Part_2942_2132808637.1461663199935--
.
Author: Moritz Klammler <moritz@klammler.eu>
Date: Tue, 26 Apr 2016 11:54:46 +0200
Raw View
>> Or some kind of a smart thread that takes a policy parameter to
>> decide whether to detach or join (dj_thread? :-)) - or, for that
>> matter, why not
>
> That solution doesn't encode the behavior into the type system, which
> would be a major deficiency, and std::future and its users suffer from
> that deficiency. I don't want to repeat that mistake.
Jeah, let's not do that again. OTOH, I would have no objections against
a solution like this
enum class thread_dtor_policy { join, detach, terminate };
template <thread_dtor_policy Policy = thread_dtor_policy::terminate, ...>
class thread;
except that it would break binary compatibility.
--
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/87r3dsoftl.fsf%40klammler.eu.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 26 Apr 2016 13:46:17 +0300
Raw View
On 26 April 2016 at 12:54, Moritz Klammler <moritz@klammler.eu> wrote:
>
>>> Or some kind of a smart thread that takes a policy parameter to
>>> decide whether to detach or join (dj_thread? :-)) - or, for that
>>> matter, why not
>>
>> That solution doesn't encode the behavior into the type system, which
>> would be a major deficiency, and std::future and its users suffer from
>> that deficiency. I don't want to repeat that mistake.
>
> Jeah, let's not do that again. OTOH, I would have no objections against
> a solution like this
>
> enum class thread_dtor_policy { join, detach, terminate };
>
> template <thread_dtor_policy Policy = thread_dtor_policy::terminate, ...>
> class thread;
>
> except that it would break binary compatibility.
Yep, there are decent reasons to avoid touching std::thread. Those
reasons are not
perhaps completely unanimously agreed on, but we do already have
large-group guidance
to add a new thread type rather than modifying std::thread, *and* I want to get
joining_thread into C++17, warts and all, imperfect as it might be. We
should not
make our users wait for yet another standard round for a perfect
solution for the
lack of a RAII thread type. Therefore I'm against redesigning
joining_thread to incorporate
policies.
--
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/CAFk2RUaQt2Ouz0AV7mWLZ_OTrY12VkAFdT1Z2iiAYGdutYVJ4A%40mail.gmail.com.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 28 Apr 2016 22:36:40 +0200
Raw View
This is a multi-part message in MIME format.
--------------040508030008000304070001
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 26/04/2016 12:46, Ville Voutilainen a =C3=A9crit :
> On 26 April 2016 at 12:54, Moritz Klammler <moritz@klammler.eu> wrote:
>>>> Or some kind of a smart thread that takes a policy parameter to
>>>> decide whether to detach or join (dj_thread? :-)) - or, for that
>>>> matter, why not
>>> That solution doesn't encode the behavior into the type system, which
>>> would be a major deficiency, and std::future and its users suffer from
>>> that deficiency. I don't want to repeat that mistake.
>> Jeah, let's not do that again. OTOH, I would have no objections against
>> a solution like this
>>
>> enum class thread_dtor_policy { join, detach, terminate };
>>
>> template <thread_dtor_policy Policy =3D thread_dtor_policy::termina=
te, ...>
>> class thread;
>>
>> except that it would break binary compatibility.
> Yep, there are decent reasons to avoid touching std::thread. Those
> reasons are not
> perhaps completely unanimously agreed on, but we do already have
> large-group guidance
> to add a new thread type rather than modifying std::thread, *and* I want =
to get
> joining_thread into C++17, warts and all, imperfect as it might be. We
> should not
> make our users wait for yet another standard round for a perfect
> solution for the
> lack of a RAII thread type. Therefore I'm against redesigning
> joining_thread to incorporate
> policies.
>
Hi,
one way to preserve the std::thread ABI and making scoped threads=20
compatible could be the following:
basic_thread - everything as thread except that do nothing on the=20
destructor. The user is the responsible to doing whatever is needed=20
before destruction.
scoped_thread<P> : basic_thread - applying P on destructor
thread - as now - An implementation could redefine it as as an alias of=20
scoped_thread<terminate> if he considers the ABI change is acceptable
joining_thread =3D scoped_thread<join>
detaching_thread=3D scoped_thread<detach>
scoped_thread<P1> can be moved (constructible/assignable) from=20
scoped_thread<P2>
scoped_thread<P1> can be moved (constructible/assignable) from thread;
Now we can have functions that accept scoped_thread<P>&& and that can be=20
used with an rvalue std::thread.
Vicente
--=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/57227458.1010807%40wanadoo.fr.
--------------040508030008000304070001
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 26/04/2016 12:46, Ville Voutilainen
a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:CAFk2RUaQt2Ouz0AV7mWLZ_OTrY12VkAFdT1Z2iiAYGdutYVJ4A@mail.gmail.=
com"
type=3D"cite">
<pre wrap=3D"">On 26 April 2016 at 12:54, Moritz Klammler <a class=3D=
"moz-txt-link-rfc2396E" href=3D"mailto:moritz@klammler.eu"><moritz@klamm=
ler.eu></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">
</pre>
<blockquote type=3D"cite">
<blockquote type=3D"cite">
<pre wrap=3D"">Or some kind of a smart thread that takes a poli=
cy parameter to
decide whether to detach or join (dj_thread? :-)) - or, for that
matter, why not
</pre>
</blockquote>
<pre wrap=3D"">
That solution doesn't encode the behavior into the type system, which
would be a major deficiency, and std::future and its users suffer from
that deficiency. I don't want to repeat that mistake.
</pre>
</blockquote>
<pre wrap=3D"">
Jeah, let's not do that again. OTOH, I would have no objections against
a solution like this
enum class thread_dtor_policy { join, detach, terminate };
template <thread_dtor_policy Policy =3D thread_dtor_policy::terminat=
e, ...>
class thread;
except that it would break binary compatibility.
</pre>
</blockquote>
<pre wrap=3D"">
Yep, there are decent reasons to avoid touching std::thread. Those
reasons are not
perhaps completely unanimously agreed on, but we do already have
large-group guidance
to add a new thread type rather than modifying std::thread, *and* I want to=
get
joining_thread into C++17, warts and all, imperfect as it might be. We
should not
make our users wait for yet another standard round for a perfect
solution for the
lack of a RAII thread type. Therefore I'm against redesigning
joining_thread to incorporate
policies.
</pre>
</blockquote>
<font size=3D"+1">Hi,<br>
<br>
one way to preserve the std::thread ABI and making scoped threads
compatible could be the following:<br>
</font><br>
<font size=3D"+1"><font size=3D"+1"><font size=3D"+1"><font size=3D"+1"=
><font
size=3D"+1"><font size=3D"+1"><font size=3D"+1"><font size=3D=
"+1">
basic_thread - everything as thread except that do
nothing on the destructor. The user is the
responsible to doing whatever is needed before
destruction.<br>
<br>
</font></font></font></font></font></font></font></font><=
font
size=3D"+1">scoped_thread<P> : </font><font size=3D"+1"><font
size=3D"+1">basic_thread - applying P on destructor<br>
</font></font><font size=3D"+1"><font size=3D"+1"><font size=3D"+1"><=
font
size=3D"+1"><font size=3D"+1"><font size=3D"+1"><br>
</font></font></font></font></font></font><br>
<font size=3D"+1"><font size=3D"+1"><font size=3D"+1"><font size=3D"+1"=
><font
size=3D"+1"><font size=3D"+1"><font size=3D"+1"><font size=3D=
"+1"><font
size=3D"+1">thread - as now - </font></font></font><f=
ont
size=3D"+1"><font size=3D"+1"><font size=3D"+1"><font
size=3D"+1"><font size=3D"+1">An implementation
could redefine it as as an alias of=C2=A0</font><=
/font></font></font></font></font></font></font></font></font></font><font
size=3D"+1"><font size=3D"+1"><font size=3D"+1"><font size=3D"+1"><fo=
nt
size=3D"+1"><font size=3D"+1"><font size=3D"+1"><font size=3D=
"+1"><font
size=3D"+1"><font size=3D"+1"><font size=3D"+1"><font
size=3D"+1"><font size=3D"+1">scoped_thread<=
terminate></font></font>
if he considers the ABI change is acceptable =C2=
=A0
<br>
</font></font></font></font></font></font></font></=
font></font></font>joining_thread
=3D </font><font size=3D"+1"><font size=3D"+1">scoped_thread<join&=
gt;<br>
</font>detaching_thread</font><font size=3D"+1"> =3D </font><font
size=3D"+1"><font size=3D"+1">scoped_thread<detach><br>
</font></font><br>
<font size=3D"+1"><font size=3D"+1"><font size=3D"+1">scoped_thread<=
P1>
can be moved </font></font></font><font size=3D"+1"><font
size=3D"+1"><font size=3D"+1"><font size=3D"+1"><font size=3D"+1"><=
font
size=3D"+1"><font size=3D"+1"><font size=3D"+1"><font
size=3D"+1"><font size=3D"+1">(constructible/assignab=
le)</font></font></font></font></font></font></font>
from </font></font></font><font size=3D"+1"><font size=3D"+1"><fo=
nt
size=3D"+1"><font size=3D"+1">scoped_thread<P2><br>
</font></font></font></font><font size=3D"+1"><font size=3D"+1"><=
font
size=3D"+1"><font size=3D"+1"><font size=3D"+1"><font size=3D"+1"=
><font
size=3D"+1">scoped_thread<P1> can be moved
(constructible/assignable) from thread;<br>
<br>
</font></font></font></font></font>Now we can have
functions that accept </font></font><font size=3D"+1"><font
size=3D"+1"><font size=3D"+1"><font size=3D"+1"><font size=3D"+1">s=
coped_thread<P>&&
and that can be used with an rvalue std::thread.<br>
<br>
<br>
</font></font></font>Vicente<br>
</font></font>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/57227458.1010807%40wanadoo.fr?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/a/isocpp.org/d/m=
sgid/std-proposals/57227458.1010807%40wanadoo.fr</a>.<br />
--------------040508030008000304070001--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 28 Apr 2016 23:41:47 +0300
Raw View
On 28 April 2016 at 23:36, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
> one way to preserve the std::thread ABI and making scoped threads compatible
> could be the following:
I already have a solution that preserves std::thread's API/ABI, and
makes 'scoped threads' compatible,
or as compatible as LEWG wanted them to be. I have also implemented it
and tested it.
--
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/CAFk2RUYHGkWRjWtMgTjwtZFoTnZEkYkuO5MgNZ8dun99soJ_Gg%40mail.gmail.com.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 28 Apr 2016 15:43:21 -0500
Raw View
--001a113e8e6c0cf687053191967a
Content-Type: text/plain; charset=UTF-8
On 28 April 2016 at 15:36, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> one way to preserve the std::thread ABI and making scoped threads
> compatible could be the following:
>
> thread - as now - An implementation could redefine it as as an alias of
> scoped_thread<terminate> if he considers the ABI change is acceptable
>
In other words, this proposal doesn't preserve the ABI.
Anyway, there are plenty of ways to skin this. We've been debating it for
five years. How many more years should we debate it before shipping it?
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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/CAGg_6%2BMnmAL%2BC6dQqNc6HDmJ0o0pJ5gstr8KEp0U-m%3D-1exEGg%40mail.gmail.com.
--001a113e8e6c0cf687053191967a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 28 April 2016 at 15:36, Vicente J. Botet Escriba <span =
dir=3D"ltr"><<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blan=
k">vicente.botet@wanadoo.fr</a>></span> wrote:<br><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><div><div class=3D"h5">
<div><span style=3D"font-size:large;color:rgb(34,34,34)">one way to pre=
serve the std::thread ABI and making scoped threads
compatible could be the following:</span><br></div></div></div><br><f=
ont size=3D"+1"><font size=3D"+1"><font size=3D"+1"><font size=3D"+1"><font=
size=3D"+1"><font size=3D"+1"><font size=3D"+1"><font size=3D"+1"><font si=
ze=3D"+1">thread - as now - </font></font></font><font size=3D"+1"><font si=
ze=3D"+1"><font size=3D"+1"><font size=3D"+1"><font size=3D"+1">An implemen=
tation
could redefine it as as an alias of=C2=A0</font><=
/font></font></font></font></font></font></font></font></font></font><font =
size=3D"+1"><font size=3D"+1"><font size=3D"+1"><font size=3D"+1"><font siz=
e=3D"+1"><font size=3D"+1"><font size=3D"+1"><font size=3D"+1"><font size=
=3D"+1"><font size=3D"+1"><font size=3D"+1"><font size=3D"+1"><font size=3D=
"+1">scoped_thread<terminate></font></font>
if he considers the ABI change is acceptable =C2=
=A0
</font></font></font></font></font></font></font></font></font></font></fon=
t></div></blockquote><div><br></div><div>In other words, this proposal does=
n't preserve the ABI.</div><div><br></div><div>Anyway, there are plenty=
of ways to skin this.=C2=A0 We've been debating it for five years.=C2=
=A0 How many more years should we debate it before shipping it?</div></div>=
-- <br><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr=
"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>> =
=C2=A0+1-847-691-1404</div></div></div></div></div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAGg_6%2BMnmAL%2BC6dQqNc6HDmJ0o0pJ5gs=
tr8KEp0U-m%3D-1exEGg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMn=
mAL%2BC6dQqNc6HDmJ0o0pJ5gstr8KEp0U-m%3D-1exEGg%40mail.gmail.com</a>.<br />
--001a113e8e6c0cf687053191967a--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Thu, 28 Apr 2016 19:26:39 -0700 (PDT)
Raw View
------=_Part_23_937232287.1461896799203
Content-Type: multipart/alternative;
boundary="----=_Part_24_76740170.1461896799203"
------=_Part_24_76740170.1461896799203
Content-Type: text/plain; charset=UTF-8
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0206r0.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0206r1.html
Ville,
I've only just read the paper and have no background on what the Committee
discussion has already been, except as recorded in
http://wiki.edg.com/bin/view/Wg21jacksonville/P0206
.. p0206r1 looks like a slam-dunk to me, except for one little piece that
confuses me:
p0206r0 proposed a "convert joining-thread to plain-old-thread" member
function with signature
thread to_thread();
and semantics "*this is set to a default constructed state. The state of
the returned object is the state *this had prior to calling this function.
Returns: A thread object initialized from *this."
In p0206r1, this has changed to
thread& as_thread();
const thread& as_thread() const;
with the note: "The functions are intentionally not ref-qualified, they
intentionally return a reference rather than a value, and it's intentional
that there are no overloads that return rvalue references."
I understand why ref-qualified functions and functions returning rvalue
references are undesirable (as a general rule). I don't understand why
functions returning *values* are undesirable, though, and p0206r1 doesn't
offer any further explanation.
Elsewhere in the standard library, we have similar cases of "I have a
(potentially non-copyable) A; I need to produce a corresponding B". My
intuition is that they're usually of the value-returning form:
- auto std::future<T>::share() -> std::shared_future<T>
- auto std::weak_ptr<T>::lock() const -> std::shared_ptr<T> (okay,
weak_ptr is copyable, so this member function gets to be const)
and there are also some of the "constructor-taking-rvalue-reference" form:
- std::shared_ptr<Y,D>::shared_ptr(std::unique_ptr<Y,D>&&)
Either way, IMO there's a strong intuition that returning pointers (or
references) into your own parameters' innards is a *bad thing*.
IMO, either (A)
std::thread as_thread(); // with semantics as in p0206r0
[...]
auto jt = make_joining_thread();
auto t = jt.as_thread();
assert(!jt.joinable());
auto t2 = make_joining_thread().as_thread();
or (B)
std::thread::thread(std::joining_thread&&);
[...]
auto jt = make_joining_thread();
auto t = std::thread(std::move(jt));
assert(!jt.joinable());
auto t2 = std::thread(make_joining_thread());
would be very much preferable to p0206r1's reference-returning versions (C)
std::thread& as_thread();
const std::thread& as_thread() const;
[...]
auto jt = make_joining_thread();
auto t = std::move(jt.as_thread());
assert(!jt.joinable());
auto t2 = std::move(make_joining_thread().as_thread());
I happen to prefer (A) because the named member function is more explicit,
but even (B) seems better to me than p0206r1's two
dangling-reference-returning signatures.
IMHO, novices (the target audience, right?) will not enjoy having to deal
with std::move and dangling references out of the box. I think they'll
prefer a version that uses value semantics and doesn't require std::move,
even if it does involve giving side-effects to a member function.
But was the Committee discussion really in favor of the reference-returning
signatures? and if so, why?
my $.02,
Arthur
--
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/32e023f0-a4f6-4914-a7ae-6a3b330e1229%40isocpp.org.
------=_Part_24_76740170.1461896799203
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/20=
16/p0206r0.html<br></div><div>http://www.open-std.org/jtc1/sc22/wg21/docs/p=
apers/2016/p0206r1.html<br></div><div><br></div><div>Ville,</div><div><br><=
/div><div>I've only just read the paper and have no background on what =
the Committee discussion has already been, except as recorded in</div><div>=
http://wiki.edg.com/bin/view/Wg21jacksonville/P0206</div><div>. p0206r1 loo=
ks like a slam-dunk to me, except for one little piece that confuses me:</d=
iv><div><br></div><div>p0206r0 proposed a "convert joining-thread to p=
lain-old-thread" member function with signature</div><div><br></div><d=
iv>=C2=A0 =C2=A0 thread to_thread();</div><div><br></div>and semantics &quo=
t;*this is set to a default constructed state. The state=C2=A0of the return=
ed object is the state *this had prior to calling this function.
Returns: A thread object initialized from *this."<div><br></div><div>=
In p0206r1, this has changed to</div><br>=C2=A0 =C2=A0 thread& as_threa=
d();<div>=C2=A0 =C2=A0 const thread& as_thread() const;</div><div><br>w=
ith the note: "The functions are intentionally not ref-qualified, they=
intentionally return a reference rather than a value, and it's intenti=
onal that there are no overloads that return rvalue references."</div>=
<div>I understand why ref-qualified functions and functions returning rvalu=
e references are undesirable (as a general rule). I don't understand wh=
y functions returning <i>values</i> are undesirable, though, and p0206r1 do=
esn't offer any further explanation.<br><div><br></div><div>Elsewhere i=
n the standard library, we have similar cases of "I have a (potentiall=
y non-copyable) A; I need to produce a corresponding B". My intuition =
is that they're usually of the value-returning form:</div><div>- auto s=
td::future<T>::share() -> std::shared_future<T><br></div><di=
v>- auto std::weak_ptr<T>::lock() const -> std::shared_ptr<T>=
; =C2=A0(okay, weak_ptr is copyable, so this member function gets to be con=
st)</div><div><br></div><div>and there are also some of the "construct=
or-taking-rvalue-reference" form:</div><div>- std::shared_ptr<Y,D&g=
t;::shared_ptr(std::unique_ptr<Y,D>&&)</div><div><br></div><d=
iv>Either way, IMO there's a strong intuition that returning pointers (=
or references) into your own parameters' innards is a <i>bad thing</i>.=
</div><div><br></div><div>IMO, either (A)</div><div><br></div><div>=C2=A0 =
=C2=A0 std::thread as_thread(); =C2=A0// with semantics as in p0206r0</div>=
<div><br></div><div>=C2=A0 =C2=A0 [...]</div><div>=C2=A0 =C2=A0 auto jt =3D=
make_joining_thread();</div><div>=C2=A0 =C2=A0 auto t =3D jt.as_thread();<=
/div><div>=C2=A0 =C2=A0 assert(!jt.joinable());<br></div><div><div>=C2=A0 =
=C2=A0 auto t2 =3D make_joining_thread().as_thread();</div></div><div><br><=
/div><div>or (B)</div><div><br></div><div>=C2=A0 =C2=A0 std::thread::thread=
(std::joining_thread&&);</div><div><br></div><div><div>=C2=A0 =C2=
=A0 [...]</div><div>=C2=A0 =C2=A0 auto jt =3D make_joining_thread();</div><=
div>=C2=A0 =C2=A0 auto t =3D std::thread(std::move(jt));</div><div>=C2=A0 =
=C2=A0 assert(!jt.joinable());<br></div></div><div><div>=C2=A0 =C2=A0 auto =
t2 =3D std::thread(make_joining_thread());</div><div><br></div></div><div>w=
ould be very much preferable to p0206r1's reference-returning versions =
(C)</div><div><br></div><div>=C2=A0 =C2=A0 std::thread& as_thread();<di=
v>=C2=A0 =C2=A0 const std::thread& as_thread() const;</div></div><div><=
br></div><div><div><div>=C2=A0 =C2=A0 [...]</div><div>=C2=A0 =C2=A0 auto jt=
=3D make_joining_thread();</div><div>=C2=A0 =C2=A0 auto t =3D std::move(jt=
..as_thread());</div><div>=C2=A0 =C2=A0 assert(!jt.joinable());<br></div></d=
iv><div>=C2=A0 =C2=A0 auto t2 =3D std::move(make_joining_thread().as_thread=
());</div></div><div><br></div><div>I happen to prefer (A) because the name=
d member function is more explicit, but even (B) seems better to me than p0=
206r1's two dangling-reference-returning signatures.</div><div><br></di=
v><div>IMHO, novices (the target audience, right?) will not enjoy having to=
deal with std::move and dangling references out of the box. I think they&#=
39;ll prefer a version that uses value semantics and doesn't require st=
d::move, even if it does involve giving side-effects to a member function.<=
/div><div><br></div></div><div>But was the Committee discussion really in f=
avor of the reference-returning signatures? and if so, why?</div><div><br><=
/div><div>my $.02,</div><div>Arthur</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/32e023f0-a4f6-4914-a7ae-6a3b330e1229%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/32e023f0-a4f6-4914-a7ae-6a3b330e1229=
%40isocpp.org</a>.<br />
------=_Part_24_76740170.1461896799203--
------=_Part_23_937232287.1461896799203--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 29 Apr 2016 09:58:20 +0300
Raw View
On 29 April 2016 at 05:26, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0206r0.html
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0206r1.html
>
> Ville,
>
> I've only just read the paper and have no background on what the Committee
> discussion has already been, except as recorded in
> http://wiki.edg.com/bin/view/Wg21jacksonville/P0206
> . p0206r1 looks like a slam-dunk to me, except for one little piece that
> confuses me:
>
> p0206r0 proposed a "convert joining-thread to plain-old-thread" member
> function with signature
>
> thread to_thread();
>
> and semantics "*this is set to a default constructed state. The state of the
> returned object is the state *this had prior to calling this function.
> Returns: A thread object initialized from *this."
>
> In p0206r1, this has changed to
>
> thread& as_thread();
> const thread& as_thread() const;
>
> with the note: "The functions are intentionally not ref-qualified, they
> intentionally return a reference rather than a value, and it's intentional
> that there are no overloads that return rvalue references."
> I understand why ref-qualified functions and functions returning rvalue
> references are undesirable (as a general rule). I don't understand why
> functions returning values are undesirable, though, and p0206r1 doesn't
> offer any further explanation.
It was pointed out that in some cases, a joining_thread needs to be
passed as a thread&
or a const thread&, and we don't want to and can't move the thread
ownership in such cases.
The value-returning approach wouldn't have allowed such passing.
> std::thread& as_thread();
> const std::thread& as_thread() const;
>
> [...]
> auto jt = make_joining_thread();
> auto t = std::move(jt.as_thread());
> assert(!jt.joinable());
> auto t2 = std::move(make_joining_thread().as_thread());
>
> I happen to prefer (A) because the named member function is more explicit,
> but even (B) seems better to me than p0206r1's two
> dangling-reference-returning signatures.
In general, the library chooses to allow forwarding rather than go out
of its way to
protect against dangling references.
--
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/CAFk2RUaaMgKC758NCcdH9mYuuxViGV-u6LSB6cpbKVGhO%3D%3DmHw%40mail.gmail.com.
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Fri, 29 Apr 2016 16:34:01 -0700 (PDT)
Raw View
------=_Part_110_1149803663.1461972841766
Content-Type: multipart/alternative;
boundary="----=_Part_111_1563384369.1461972841766"
------=_Part_111_1563384369.1461972841766
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, April 28, 2016 at 11:58:22 PM UTC-7, Ville Voutilainen wrote:
>
> On 29 April 2016 at 05:26, Arthur O'Dwyer <arthur....@gmail.com=20
> <javascript:>> wrote:=20
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0206r0.html=20
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0206r1.html=20
> >=20
> > Ville,=20
> >=20
> > I've only just read the paper and have no background on what the=20
> Committee=20
> > discussion has already been, except as recorded in=20
> > http://wiki.edg.com/bin/view/Wg21jacksonville/P0206=20
> > . p0206r1 looks like a slam-dunk to me, except for one little piece tha=
t=20
> > confuses me:=20
> >=20
> > p0206r0 proposed a "convert joining-thread to plain-old-thread" member=
=20
> > function with signature=20
> >=20
> > thread to_thread();=20
> >=20
> > and semantics "*this is set to a default constructed state. The state o=
f=20
> the=20
> > returned object is the state *this had prior to calling this function.=
=20
> > Returns: A thread object initialized from *this."=20
> >=20
> > In p0206r1, this has changed to=20
> >=20
> > thread& as_thread();=20
> > const thread& as_thread() const;=20
> >=20
> > with the note: "The functions are intentionally not ref-qualified, they=
=20
> > intentionally return a reference rather than a value, and it's=20
> intentional=20
> > that there are no overloads that return rvalue references."=20
> > I understand why ref-qualified functions and functions returning rvalue=
=20
> > references are undesirable (as a general rule). I don't understand why=
=20
> > functions returning values are undesirable, though, and p0206r1 doesn't=
=20
> > offer any further explanation.=20
>
> It was pointed out that in some cases, a joining_thread needs to be=20
> passed as a thread&=20
> or a const thread&, and we don't want to and can't move the thread=20
> ownership in such cases.=20
> The value-returning approach wouldn't have allowed such passing.=20
>
And we can't just have joining_thread inherit from thread, because that=20
would invite slicing bugs, right?
Okay, I guess that makes sense; at least I can't think of a=20
non-returning-internal-references solution. Thanks for the explanation.
=E2=80=93Arthur
--=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/1bbe2923-d31f-4bce-af9b-e4d069412df6%40isocpp.or=
g.
------=_Part_111_1563384369.1461972841766
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, April 28, 2016 at 11:58:22 PM UTC-7, Ville Vo=
utilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 29 April 20=
16 at 05:26, Arthur O'Dwyer <<a href=3D"javascript:" target=3D"_blan=
k" gdf-obfuscated-mailto=3D"5TFDNkGABAAJ" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
javascript:';return true;">arthur....@gmail.com</a>> wrote:
<br>> <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016=
/p0206r0.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1=
%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0206r0.html\x26sa\x3dD\x26sntz\x3d=
1\x26usg\x3dAFQjCNHARqFUJSVqbFkiQkTmzB1MhNeODA';return true;" onclick=
=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-s=
td.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0206r0.html\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNHARqFUJSVqbFkiQkTmzB1MhNeODA';return tru=
e;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2016/<wbr>p0206=
r0.html</a>
<br>> <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016=
/p0206r1.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1=
%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0206r1.html\x26sa\x3dD\x26sntz\x3d=
1\x26usg\x3dAFQjCNG0pcPkUB8pogk5wOFAFymT7uH9_g';return true;" onclick=
=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-s=
td.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0206r1.html\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNG0pcPkUB8pogk5wOFAFymT7uH9_g';return tru=
e;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2016/<wbr>p0206=
r1.html</a>
<br>>
<br>> Ville,
<br>>
<br>> I've only just read the paper and have no background on what t=
he Committee
<br>> discussion has already been, except as recorded in
<br>> <a href=3D"http://wiki.edg.com/bin/view/Wg21jacksonville/P0206" ta=
rget=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www=
..google.com/url?q\x3dhttp%3A%2F%2Fwiki.edg.com%2Fbin%2Fview%2FWg21jacksonvi=
lle%2FP0206\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHRL3vnFUCJEq-b3eYhAW9Ou=
vKkwA';return true;" onclick=3D"this.href=3D'http://www.google.com/=
url?q\x3dhttp%3A%2F%2Fwiki.edg.com%2Fbin%2Fview%2FWg21jacksonville%2FP0206\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHRL3vnFUCJEq-b3eYhAW9OuvKkwA';r=
eturn true;">http://wiki.edg.com/bin/view/<wbr>Wg21jacksonville/P0206</a>
<br>> . p0206r1 looks like a slam-dunk to me, except for one little piec=
e that
<br>> confuses me:
<br>>
<br>> p0206r0 proposed a "convert joining-thread to plain-old-threa=
d" member
<br>> function with signature
<br>>
<br>> =C2=A0 =C2=A0 thread to_thread();
<br>>
<br>> and semantics "*this is set to a default constructed state. T=
he state of the
<br>> returned object is the state *this had prior to calling this funct=
ion.
<br>> Returns: A thread object initialized from *this."
<br>>
<br>> In p0206r1, this has changed to
<br>>
<br>> =C2=A0 =C2=A0 thread& as_thread();
<br>> =C2=A0 =C2=A0 const thread& as_thread() const;
<br>>
<br>> with the note: "The functions are intentionally not ref-quali=
fied, they
<br>> intentionally return a reference rather than a value, and it's=
intentional
<br>> that there are no overloads that return rvalue references."
<br>> I understand why ref-qualified functions and functions returning r=
value
<br>> references are undesirable (as a general rule). I don't unders=
tand why
<br>> functions returning values are undesirable, though, and p0206r1 do=
esn't
<br>> offer any further explanation.
<br>
<br>It was pointed out that in some cases, a joining_thread needs to be
<br>passed as a thread&
<br>or a const thread&, and we don't want to and can't move the=
thread
<br>ownership in such cases.
<br>The value-returning approach wouldn't have allowed such passing.
<br></blockquote><div><br></div><div>And we can't just have joining_thr=
ead inherit from thread, because that would invite slicing bugs, right?</di=
v><div>Okay, I guess that makes sense; at least I can't think of a non-=
returning-internal-references solution. Thanks for the explanation.</div><d=
iv><br></div><div>=E2=80=93Arthur</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/1bbe2923-d31f-4bce-af9b-e4d069412df6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1bbe2923-d31f-4bce-af9b-e4d069412df6=
%40isocpp.org</a>.<br />
------=_Part_111_1563384369.1461972841766--
------=_Part_110_1149803663.1461972841766--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 30 Apr 2016 02:42:17 +0300
Raw View
On 30 April 2016 at 02:34, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:
>> It was pointed out that in some cases, a joining_thread needs to be
>> passed as a thread&
>> or a const thread&, and we don't want to and can't move the thread
>> ownership in such cases.
>> The value-returning approach wouldn't have allowed such passing.
> And we can't just have joining_thread inherit from thread, because that
> would invite slicing bugs, right?
Precisely so. Having std::joining_thread publicly inherit std::thread
would invite
an implicit conversion from, for lack of better strawman words, 'safe'
to 'unsafe', hence not proposing such
an inheritance relation.
--
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/CAFk2RUZkBCh23NLEa%2B-V_zfet0DcJQ9n3NVPvBsEuNTmUECBcg%40mail.gmail.com.
.