Topic: Should there be a Standard Library function to
Author: Patrice Roy <patricer@gmail.com>
Date: Mon, 31 Oct 2016 14:53:27 -0400
Raw View
--f403045e2f122bcd8a05402db969
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Would you have sample potential user code to provide? The dynamic between
the throwing thread and the thread on the receiver end are not self-evident
from a code-writing perspective (e.g. can you throw an exception to any
thread whose id you know? Are they expected to be aware they are =C2=ABunde=
r
attack=C2=BB in such a way?)
An idea as to the envisioned benefits of such a strange beast would also be
appreciated.
Thanks.
2016-10-31 14:31 GMT-04:00 'Walt Karas' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org>:
> Something like:
>
> template <typename T>
> void async_throw(std::thread::id target_thread, const T
> ©able_object_to_throw);
>
> This doesn't seem like it would be that hard to implement. One
> implementation would involve the compiler generating a table of two-field
> entries:
>
> ( start of instruction pointer address range, pointer to handling code )
>
> The start address of the next entry would be the end of the range for an
> entry. A binary search using the current instruction pointer of the targ=
et
> thread would find the correct table entry, and thus the pointer to the
> handling code.
>
> Implementations could allow this function to be called from signal
> handling routines and interrupt service routines.
>
> Adding this function would probably necessitate a compiler option to
> ignore noexcept specifiers.
>
> --
> 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/b06561bd-a1ef-42af-
> 828b-4327d473dcfc%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b06561bd-a1=
ef-42af-828b-4327d473dcfc%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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/CAKiZDp0d2TC0W9FDFN2sbf-bp3QRjvmwNw4jOXJMPvQfyM7=
PJQ%40mail.gmail.com.
--f403045e2f122bcd8a05402db969
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>Would you have sample potential user code to pro=
vide? The dynamic between the throwing thread and the thread on the receive=
r end are not self-evident from a code-writing perspective (e.g. can you th=
row an exception to any thread whose id you know? Are they expected to be a=
ware they are =C2=ABunder attack=C2=BB in such a way?)<br><br></div>An idea=
as to the envisioned benefits of such a strange beast would also be apprec=
iated.<br><br></div>Thanks.<br></div><div class=3D"gmail_extra"><br><div cl=
ass=3D"gmail_quote">2016-10-31 14:31 GMT-04:00 'Walt Karas' via ISO=
C++ Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:st=
d-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>><=
/span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Something like:<=
div><br></div><div>template <typename T></div><div>void async_throw(s=
td::thread::id target_thread, const T &copyable_object_to_throw);</div>=
<div><br></div><div>This doesn't seem like it would be that hard to imp=
lement.=C2=A0 One implementation would involve the compiler generating a ta=
ble of two-field entries:</div><div><br></div><div>( start of instruction p=
ointer address range, pointer to handling code )</div><div><br></div><div>T=
he start address of the next entry would be the end of the range for an ent=
ry.=C2=A0 A binary search using the current instruction pointer of the targ=
et thread would find the correct table entry, and thus the pointer to the h=
andling code.</div><div><br></div><div>Implementations could allow this fun=
ction to be called from signal handling routines and interrupt service rout=
ines.</div><div><br></div><div>Adding this function would probably necessit=
ate a compiler option to ignore noexcept specifiers.</div></div><span class=
=3D"HOEnZb"><font color=3D"#888888">
<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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/b06561bd-a1ef-42af-828b-4327d473dcfc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/b065=
61bd-a1ef-42af-<wbr>828b-4327d473dcfc%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br></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/CAKiZDp0d2TC0W9FDFN2sbf-bp3QRjvmwNw4j=
OXJMPvQfyM7PJQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp0d2TC0W9FD=
FN2sbf-bp3QRjvmwNw4jOXJMPvQfyM7PJQ%40mail.gmail.com</a>.<br />
--f403045e2f122bcd8a05402db969--
.
Author: Andrey Semashev <andrey.semashev@gmail.com>
Date: Mon, 31 Oct 2016 21:58:40 +0300
Raw View
On 10/31/16 21:31, 'Walt Karas' via ISO C++ Standard - Future Proposals
wrote:
> Something like:
>
> template <typename T>
> void async_throw(std::thread::id target_thread, const T
> ©able_object_to_throw);
>
> This doesn't seem like it would be that hard to implement. One
> implementation would involve the compiler generating a table of
> two-field entries:
>
> ( start of instruction pointer address range, pointer to handling code )
>
> The start address of the next entry would be the end of the range for an
> entry. A binary search using the current instruction pointer of the
> target thread would find the correct table entry, and thus the pointer
> to the handling code.
In order to throw an exception, the victim thread has to execute some
piece of code. You cannot impose an exception on an unsuspecting thread.
The closest thing you could do is use interruption points from
Boost.Thread, but this feature is not cost-free in terms of performance,
and I don't think it will be standardized.
> Implementations could allow this function to be called from signal
> handling routines and interrupt service routines.
Your signal handler has to cooperate with other threads. The typical
solution is to use a flag that is regularly checked by the threads.
> Adding this function would probably necessitate a compiler option to
> ignore noexcept specifiers.
I don't think this is viable. It breaks programmer expectations wrt.
exception safety, for starters.
--
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/331b8469-0c5a-1387-c870-1c066cdb5682%40gmail.com.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 31 Oct 2016 14:09:14 -0500
Raw View
--001a1144033206205305402df48f
Content-Type: text/plain; charset=UTF-8
On Mon, Oct 31, 2016 at 1:31 PM, 'Walt Karas' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
> Something like:
>
> template <typename T>
> void async_throw(std::thread::id target_thread, const T
> ©able_object_to_throw);
>
No. Not to be harsh, but this is a pretty awful idea.
Take the following shared variables:
std::mutex m;
unsigned a;
unsigned b;
Given this piece of code:
m.lock();
++a;
--b;
m.unlock();
If an exception is thrown while processing --b, how exactly do you plan on
recovering?
--
>
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%2BMc8ruPXj3y2wmnJvA5%3DmOvjk%2BnC9RAESFyvLwf_R62OA%40mail.gmail.com.
--001a1144033206205305402df48f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Oct 31, 2016 at 1:31 PM, 'Walt Karas' via =
ISO C++ Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"mailto=
:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&g=
t;</span> wrote:<br><div class=3D"gmail_extra"><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"><div dir=3D"ltr">Something like:<div><br></di=
v><div>template <typename T></div><div>void async_throw(std::thread::=
id target_thread, const T &copyable_object_to_throw);</div><div></div><=
/div></blockquote><div><br></div><div>No.=C2=A0 Not to be harsh, but this i=
s a pretty awful idea.</div><div><br></div><div>Take the following shared v=
ariables:</div><div><br></div><div><font face=3D"monospace, monospace">std:=
:mutex m;</font></div><div><font face=3D"monospace, monospace">unsigned a;<=
/font></div><div><font face=3D"monospace, monospace">unsigned b;=C2=A0</fon=
t></div><div><br></div><div>Given this piece of code:</div><div><br></div><=
div><font face=3D"monospace, monospace">m.lock();</font></div><div><font fa=
ce=3D"monospace, monospace">++a;</font></div><div><font face=3D"monospace, =
monospace">--b;</font></div><div><font face=3D"monospace, monospace">m.unlo=
ck();</font></div><div><br></div><div>If an exception is thrown while proce=
ssing <font face=3D"monospace, monospace">--b</font>, how exactly do you pl=
an on recovering?</div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div>--=C2=A0<br></div></div></blockquote></div><div class=3D"gm=
ail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><di=
v dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a hr=
ef=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.c=
om</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%2BMc8ruPXj3y2wmnJvA5%3DmOvjk%2=
BnC9RAESFyvLwf_R62OA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMc=
8ruPXj3y2wmnJvA5%3DmOvjk%2BnC9RAESFyvLwf_R62OA%40mail.gmail.com</a>.<br />
--001a1144033206205305402df48f--
.
Author: "'Walt Karas' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Mon, 31 Oct 2016 12:18:49 -0700 (PDT)
Raw View
------=_Part_1481_1307678787.1477941529596
Content-Type: multipart/alternative;
boundary="----=_Part_1482_899159304.1477941529596"
------=_Part_1482_899159304.1477941529596
Content-Type: text/plain; charset=UTF-8
On Monday, October 31, 2016 at 2:58:45 PM UTC-4, Andrey Semashev wrote:
>
> On 10/31/16 21:31, 'Walt Karas' via ISO C++ Standard - Future Proposals
> wrote:
> > Something like:
> >
> > template <typename T>
> > void async_throw(std::thread::id target_thread, const T
> > ©able_object_to_throw);
> >
> > This doesn't seem like it would be that hard to implement. One
> > implementation would involve the compiler generating a table of
> > two-field entries:
> >
> > ( start of instruction pointer address range, pointer to handling code )
> >
> > The start address of the next entry would be the end of the range for an
> > entry. A binary search using the current instruction pointer of the
> > target thread would find the correct table entry, and thus the pointer
> > to the handling code.
>
> In order to throw an exception, the victim thread has to execute some
> piece of code. You cannot impose an exception on an unsuspecting thread.
> The closest thing you could do is use interruption points from
> Boost.Thread, but this feature is not cost-free in terms of performance,
> and I don't think it will be standardized.
>
> > Implementations could allow this function to be called from signal
> > handling routines and interrupt service routines.
>
> Your signal handler has to cooperate with other threads. The typical
> solution is to use a flag that is regularly checked by the threads.
>
> > Adding this function would probably necessitate a compiler option to
> > ignore noexcept specifiers.
>
> I don't think this is viable. It breaks programmer expectations wrt.
> exception safety, for starters.
>
>
Yes, the viability is questionable, true.
Instead of disabling noexcept, perhaps the handling code could, as needed,
step backward in the stack to find the return address that exited the
top-level noexecpt function. It could back-patch this return address to
jump back into exception handling code, and then allow execution of the
noexcept code to continue (till it popped the back-patched return address).
The drawback is that the asynchronous throw mechanism could not be used
with something like a segment violation signal.
--
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/278495b3-a81c-491b-9894-ac717df79c3a%40isocpp.org.
------=_Part_1482_899159304.1477941529596
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, October 31, 2016 at 2:58:45 PM UTC-4, A=
ndrey Semashev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 10/31/=
16 21:31, 'Walt Karas' via ISO C++ Standard - Future Proposals=20
<br>wrote:
<br>> Something like:
<br>>
<br>> template <typename T>
<br>> void async_throw(std::thread::id target_thread, const T
<br>> &copyable_object_to_throw);
<br>>
<br>> This doesn't seem like it would be that hard to implement. =C2=
=A0One
<br>> implementation would involve the compiler generating a table of
<br>> two-field entries:
<br>>
<br>> ( start of instruction pointer address range, pointer to handling =
code )
<br>>
<br>> The start address of the next entry would be the end of the range =
for an
<br>> entry. =C2=A0A binary search using the current instruction pointer=
of the
<br>> target thread would find the correct table entry, and thus the poi=
nter
<br>> to the handling code.
<br>
<br>In order to throw an exception, the victim thread has to execute some=
=20
<br>piece of code. You cannot impose an exception on an unsuspecting thread=
..=20
<br>The closest thing you could do is use interruption points from=20
<br>Boost.Thread, but this feature is not cost-free in terms of performance=
,=20
<br>and I don't think it will be standardized.
<br>
<br>> Implementations could allow this function to be called from signal
<br>> handling routines and interrupt service routines.
<br>
<br>Your signal handler has to cooperate with other threads. The typical=20
<br>solution is to use a flag that is regularly checked by the threads.
<br>
<br>> Adding this function would probably necessitate a compiler option =
to
<br>> ignore noexcept specifiers.
<br>
<br>I don't think this is viable. It breaks programmer expectations wrt=
..=20
<br>exception safety, for starters.
<br>
<br></blockquote><div><br></div><div>Yes, the viability is questionable, tr=
ue.</div><div><br></div><div>Instead of disabling noexcept, perhaps the han=
dling code could, as needed, step backward in the stack to find the return =
address that exited the top-level noexecpt function. =C2=A0It could back-pa=
tch this return address to jump back into exception handling code, and then=
allow execution of the noexcept code to continue (till it popped the back-=
patched return address). =C2=A0The drawback is that the asynchronous throw =
mechanism could not be used with something like a segment violation signal.=
</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/278495b3-a81c-491b-9894-ac717df79c3a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/278495b3-a81c-491b-9894-ac717df79c3a=
%40isocpp.org</a>.<br />
------=_Part_1482_899159304.1477941529596--
------=_Part_1481_1307678787.1477941529596--
.
Author: "'Walt Karas' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Mon, 31 Oct 2016 12:27:50 -0700 (PDT)
Raw View
------=_Part_1314_517576744.1477942070875
Content-Type: multipart/alternative;
boundary="----=_Part_1315_1965374049.1477942070875"
------=_Part_1315_1965374049.1477942070875
Content-Type: text/plain; charset=UTF-8
On Monday, October 31, 2016 at 3:09:57 PM UTC-4, Nevin ":-)" Liber wrote:
>
> On Mon, Oct 31, 2016 at 1:31 PM, 'Walt Karas' via ISO C++ Standard -
> Future Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>
>> Something like:
>>
>> template <typename T>
>> void async_throw(std::thread::id target_thread, const T
>> ©able_object_to_throw);
>>
>
> No. Not to be harsh, but this is a pretty awful idea.
>
> Take the following shared variables:
>
> std::mutex m;
> unsigned a;
> unsigned b;
>
> Given this piece of code:
>
> m.lock();
> ++a;
> --b;
> m.unlock();
>
> If an exception is thrown while processing --b, how exactly do you plan
> on recovering?
>
As I noted in my response to Andrey, I accept that not respecting noexcept
is an untenable idea. So, if noexcept is respected, you could put the
above code into a noexcept function or lambda expression.
--
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/d64570c7-12a4-4819-93c8-c59ff4fe5e83%40isocpp.org.
------=_Part_1315_1965374049.1477942070875
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Monday, October 31, 2016 at 3:09:57 PM UTC-4, Nevin=
":-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr">On Mon, Oct 31, 2016 at 1:31 PM, 'Walt Karas' via I=
SO C++ Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"BYk8tlpxBAAJ" rel=3D"nofol=
low" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">std-pr...@isocpp.org</a=
>></span> wrote:<br><div><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"><div dir=3D"ltr">Something like:<div><br></div><div>template <=
;typename T></div><div>void async_throw(std::thread::id target_thread, c=
onst T &copyable_object_to_throw);</div><div></div></div></blockquote><=
div><br></div><div>No.=C2=A0 Not to be harsh, but this is a pretty awful id=
ea.</div><div><br></div><div>Take the following shared variables:</div><div=
><br></div><div><font face=3D"monospace, monospace">std::mutex m;</font></d=
iv><div><font face=3D"monospace, monospace">unsigned a;</font></div><div><f=
ont face=3D"monospace, monospace">unsigned b;=C2=A0</font></div><div><br></=
div><div>Given this piece of code:</div><div><br></div><div><font face=3D"m=
onospace, monospace">m.lock();</font></div><div><font face=3D"monospace, mo=
nospace">++a;</font></div><div><font face=3D"monospace, monospace">--b;</fo=
nt></div><div><font face=3D"monospace, monospace">m.unlock();</font></div><=
div><br></div><div>If an exception is thrown while processing <font face=3D=
"monospace, monospace">--b</font>, how exactly do you plan on recovering?</=
div></div></div></div></blockquote><div><br></div><div>As I noted in my res=
ponse to Andrey, I accept that not respecting noexcept is an untenable idea=
.. =C2=A0So, if noexcept is respected, you could put the above code into a n=
oexcept function or lambda expression.</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/d64570c7-12a4-4819-93c8-c59ff4fe5e83%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d64570c7-12a4-4819-93c8-c59ff4fe5e83=
%40isocpp.org</a>.<br />
------=_Part_1315_1965374049.1477942070875--
------=_Part_1314_517576744.1477942070875--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 31 Oct 2016 12:31:41 -0700 (PDT)
Raw View
------=_Part_2151_349240383.1477942301460
Content-Type: multipart/alternative;
boundary="----=_Part_2152_1521528176.1477942301460"
------=_Part_2152_1521528176.1477942301460
Content-Type: text/plain; charset=UTF-8
On Monday, October 31, 2016 at 3:09:57 PM UTC-4, Nevin ":-)" Liber wrote:
>
> On Mon, Oct 31, 2016 at 1:31 PM, 'Walt Karas' via ISO C++ Standard -
> Future Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>
>> Something like:
>>
>> template <typename T>
>> void async_throw(std::thread::id target_thread, const T
>> ©able_object_to_throw);
>>
>
> No. Not to be harsh, but this is a pretty awful idea.
>
While this idea is pretty terrible, I think that it wouldn't be
unreasonable to standardize a *cooperative* mechanism for doing so.
Something like Boost.Thread's interruption points.
Essentially, it'd be like a reverse promise/future. The "promises" could be
shared, with multiple threads being able to submit an exception. But the
"future" would be unique.
--
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/d67ea09a-41b0-48da-8868-64bd118e3927%40isocpp.org.
------=_Part_2152_1521528176.1477942301460
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, October 31, 2016 at 3:09:57 PM UTC-4, Nevin &qu=
ot;:-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr">On Mon, Oct 31, 2016 at 1:31 PM, 'Walt Karas' via ISO C=
++ Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"BYk8tlpxBAAJ" rel=3D"nofollow"=
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"=
this.href=3D'javascript:';return true;">std-pr...@isocpp.org</a>>=
;</span> wrote:<br><div><div class=3D"gmail_quote"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">Something like:<div><br></div><div>template <typ=
ename T></div><div>void async_throw(std::thread::id target_thread, const=
T &copyable_object_to_throw);</div><div></div></div></blockquote><div>=
<br></div><div>No.=C2=A0 Not to be harsh, but this is a pretty awful idea.<=
/div></div></div></div></blockquote><div><br>While this idea is pretty terr=
ible, I think that it wouldn't be unreasonable to standardize a <i>coop=
erative</i> mechanism for doing so. Something like Boost.Thread's inter=
ruption points.<br><br>Essentially, it'd be like a reverse promise/futu=
re. The "promises" could be shared, with multiple threads being a=
ble to submit an exception. But the "future" would be unique.<br>=
</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/d67ea09a-41b0-48da-8868-64bd118e3927%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d67ea09a-41b0-48da-8868-64bd118e3927=
%40isocpp.org</a>.<br />
------=_Part_2152_1521528176.1477942301460--
------=_Part_2151_349240383.1477942301460--
.
Author: Christof Meerwald <cmeerw@cmeerw.org>
Date: Mon, 31 Oct 2016 20:48:30 +0100
Raw View
On Mon, Oct 31, 2016 at 11:31:15AM -0700, 'Walt Karas' via ISO C++ Standard - Future Proposals wrote:
> Something like:
>
> template <typename T>
> void async_throw(std::thread::id target_thread, const T
> ©able_object_to_throw);
Reminds me of PTHREAD_CANCEL_ASYNCHRONOUS - is anyone actually using
this?
Note that POSIX imposes tough restriction on this feature: "Finally,
only functions that are cancel-safe may be called from a thread that
is asynchronously cancelable."
Christof
--
http://cmeerw.org sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org
--
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/20161031194829.GT22116%40edge.cmeerw.net.
.
Author: "'Walt Karas' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Mon, 31 Oct 2016 13:06:28 -0700 (PDT)
Raw View
------=_Part_1450_995116404.1477944388503
Content-Type: multipart/alternative;
boundary="----=_Part_1451_1216922445.1477944388503"
------=_Part_1451_1216922445.1477944388503
Content-Type: text/plain; charset=UTF-8
On Monday, October 31, 2016 at 3:31:41 PM UTC-4, Nicol Bolas wrote:
>
> On Monday, October 31, 2016 at 3:09:57 PM UTC-4, Nevin ":-)" Liber wrote:
>>
>> On Mon, Oct 31, 2016 at 1:31 PM, 'Walt Karas' via ISO C++ Standard -
>> Future Proposals <std-pr...@isocpp.org> wrote:
>>
>>> Something like:
>>>
>>> template <typename T>
>>> void async_throw(std::thread::id target_thread, const T
>>> ©able_object_to_throw);
>>>
>>
>> No. Not to be harsh, but this is a pretty awful idea.
>>
>
> While this idea is pretty terrible, I think that it wouldn't be
> unreasonable to standardize a *cooperative* mechanism for doing so.
> Something like Boost.Thread's interruption points.
>
> Essentially, it'd be like a reverse promise/future. The "promises" could
> be shared, with multiple threads being able to submit an exception. But the
> "future" would be unique.
>
The implementation is problematic. But the goal is not terrible, given
that lock-free synchronization is supported by C++. When one thread
synchronizes with another, it's not clean for it to have logic to deal with
any exceptional situations that may have happened in the other thread at
each point of synchronization. It's the same reasoning that a caller does
not generally want to deal with exceptional situations that may have arisen
during a function call.
A compromise position would be to have only inter-thread locks check for
exceptions triggered from other threads, and then throwing an exception
within the target thread. With the trade-off being that, the need of one
thread to handle exceptional situations in another would make lock-free
synchronization a difficult option.
--
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/ee1671dd-0587-4699-9bb5-1d154d0ed462%40isocpp.org.
------=_Part_1451_1216922445.1477944388503
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, October 31, 2016 at 3:31:41 PM UTC-4, Nicol Bol=
as wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On M=
onday, October 31, 2016 at 3:09:57 PM UTC-4, Nevin ":-)" Liber wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Mon, Oct 31=
, 2016 at 1:31 PM, 'Walt Karas' via ISO C++ Standard - Future Propo=
sals <span dir=3D"ltr"><<a rel=3D"nofollow">std-pr...@isocpp.org</a>>=
</span> wrote:<br><div><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">Something like:<div><br></div><div>template <type=
name T></div><div>void async_throw(std::thread::id target_thread, const =
T &copyable_object_to_throw);</div><div></div></div></blockquote><div><=
br></div><div>No.=C2=A0 Not to be harsh, but this is a pretty awful idea.</=
div></div></div></div></blockquote><div><br>While this idea is pretty terri=
ble, I think that it wouldn't be unreasonable to standardize a <i>coope=
rative</i> mechanism for doing so. Something like Boost.Thread's interr=
uption points.<br><br>Essentially, it'd be like a reverse promise/futur=
e. The "promises" could be shared, with multiple threads being ab=
le to submit an exception. But the "future" would be unique.<br><=
/div></div></blockquote><div><br></div><div>The implementation is problemat=
ic. =C2=A0But the goal is not terrible, given that lock-free synchronizatio=
n is supported by C++. =C2=A0When one thread synchronizes with another, it&=
#39;s not clean for it to have logic to deal with any exceptional situation=
s that may have happened in the other thread at each point of synchronizati=
on. =C2=A0 It's the same reasoning that a caller does not generally wan=
t to deal with exceptional situations that may have arisen during a functio=
n call.</div><div><br></div><div>A compromise position would be to have onl=
y inter-thread locks check for exceptions triggered from other threads, and=
then throwing an exception within the target thread. =C2=A0With the trade-=
off being that, the need of one thread to handle exceptional situations in =
another would make lock-free synchronization a difficult option.</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/ee1671dd-0587-4699-9bb5-1d154d0ed462%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ee1671dd-0587-4699-9bb5-1d154d0ed462=
%40isocpp.org</a>.<br />
------=_Part_1451_1216922445.1477944388503--
------=_Part_1450_995116404.1477944388503--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 31 Oct 2016 16:05:18 -0700
Raw View
On segunda-feira, 31 de outubro de 2016 21:58:40 PDT Andrey Semashev wrote:
> > Adding this function would probably necessitate a compiler option to
> > ignore noexcept specifiers.
>
> I don't think this is viable. It breaks programmer expectations wrt.
> exception safety, for starters.
I think this is a non-starter.
This feature, if accepted, should be handled like POSIX thread cancellation
(which we discussed a month or two ago): the same functions that are allowed
to cancel the thread of execution are allowed to throw. Basically, this
feature would be pthread_cancel, but with more information being carried, so
the code being unwound can tell why that is happening.
I'm not talking about asynchronous cancellation. This is about synchronous
cancellation.
Then there's also the question: can the exception thus thrown be intercepted
and stopped? Or is the thread required to exit?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/7036935.23koKCOg1q%40tjmaciei-mobl1.
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 1 Nov 2016 10:22:51 -0400
Raw View
--94eb2c11be5c44e9e105403e0f60
Content-Type: text/plain; charset=UTF-8
On Mon, Oct 31, 2016 at 3:31 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Monday, October 31, 2016 at 3:09:57 PM UTC-4, Nevin ":-)" Liber wrote:
>>
>> On Mon, Oct 31, 2016 at 1:31 PM, 'Walt Karas' via ISO C++ Standard -
>> Future Proposals <std-pr...@isocpp.org> wrote:
>>
>>> Something like:
>>>
>>> template <typename T>
>>> void async_throw(std::thread::id target_thread, const T
>>> ©able_object_to_throw);
>>>
>>
>> No. Not to be harsh, but this is a pretty awful idea.
>>
>
> While this idea is pretty terrible, I think that it wouldn't be
> unreasonable to standardize a *cooperative* mechanism for doing so.
>
+1
I'm generally not fond of such interruption points in code, but in the
cases that they are desired/needed, they basically have to be cooperative.
--
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/CANh8DEk%2BDR3N4ANF_DPFrSULmKiSW%3DncDtwr6jsrYOnsZednjg%40mail.gmail.com.
--94eb2c11be5c44e9e105403e0f60
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Oct 31, 2016 at 3:31 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=
=3D"">On Monday, October 31, 2016 at 3:09:57 PM UTC-4, Nevin ":-)"=
; Liber wrote:</span><span class=3D""><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr">On Mon, Oct 31, 2016 at 1:31 PM, 'Walt Karas' v=
ia ISO C++ Standard - Future Proposals <span dir=3D"ltr"><<a rel=3D"nofo=
llow">std-pr...@isocpp.org</a>></span> wrote:<br><div><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Something like:<di=
v><br></div><div>template <typename T></div><div>void async_throw(std=
::thread::id target_thread, const T &copyable_object_to_throw);</div><d=
iv></div></div></blockquote><div><br></div><div>No.=C2=A0 Not to be harsh, =
but this is a pretty awful idea.</div></div></div></div></blockquote></span=
><div><br>While this idea is pretty terrible, I think that it wouldn't =
be unreasonable to standardize a <i>cooperative</i> mechanism for doing so.=
</div></div></blockquote><div><br></div><div>+1</div><div><br></div><div>I&=
#39;m generally not fond of such interruption points in code, but in the ca=
ses that they are desired/needed, they basically have to be cooperative.</d=
iv></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/CANh8DEk%2BDR3N4ANF_DPFrSULmKiSW%3Dnc=
Dtwr6jsrYOnsZednjg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEk%2BDR=
3N4ANF_DPFrSULmKiSW%3DncDtwr6jsrYOnsZednjg%40mail.gmail.com</a>.<br />
--94eb2c11be5c44e9e105403e0f60--
.