Topic: Supporting early termination in std::promise
Author: "'Geoffrey Romer' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 25 Jul 2014 07:58:12 -0700
Raw View
--001a11c2e8f06963b804ff05cdf8
Content-Type: text/plain; charset=UTF-8
Hi-
It seems to me that it should be fairly straightforward to extend
std::promise with a method that reports whether its state is shared with
any "asynchronous return objects" (e.g. future, shared_future). This is
valuable because it would enable the holder of a std::promise to terminate
its work early if it knows that nobody will be able to access the result
(e.g. if the work was initiated speculatively, or was canceled due to user
intervention or a consumer-side timeout).
With the current standard, producers and consumers must establish some sort
of side-channel for signaling these conditions, but this requires the
producer and consumer to agree on the API for it (exactly the sort of
problem that standards exist to solve). Furthermore, it's error-prone,
because consumers may fail to send a signal before destroying the future,
or may send the signal prematurely (e.g. if one holder of a shared_future
requests cancellation when others wish to continue)
I suspect that the necessary infrastructure to support this is already
present in many if not all implementations of std::promise; it looks like
it would be trivial in libstdc++ and libc++, for example.
I see a few open questions:
- The bikeshed question: what to name the method. Options include
"canceled", "orphaned", or "ignored", or (with the meaning inverted)
"has_future" or "viable". "abandoned" is tempting, but conflicts with the
existing meaning of "abandon" in this context.
- Is there a need for an API to "detach" a promise, so that the computation
is not abandoned even if the future is destroyed (e.g. because the
computation is needed for its side effects rather than its result)? My
hunch is that no, a computation like that will generally "know" it's being
used that way, and so won't hold a promise in the first place, much less
poll it for cancellation.
- Is there a need for a weak_future, representing a sort of "opportunistic"
consumer whose existence does not prevent the producer from terminating
early?
Does this seem like a viable extension?
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c2e8f06963b804ff05cdf8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi-<div><br></div><div>It seems to me that it should be fa=
irly straightforward to extend std::promise with a method that reports whet=
her its state is shared with any "asynchronous return objects" (e=
..g. future, shared_future). This is valuable because it would enable the ho=
lder of a std::promise to terminate its work early if it knows that nobody =
will be able to access the result (e.g. if the work was initiated speculati=
vely, or was canceled due to user intervention or a consumer-side timeout).=
=C2=A0</div>
<div><br></div><div>With the current standard, producers and consumers must=
establish some sort of side-channel for signaling these conditions, but th=
is requires the producer and consumer to agree on the API for it (exactly t=
he sort of problem that standards exist to solve). Furthermore, it's er=
ror-prone, because consumers may fail to send a signal before destroying th=
e future, or may send the signal prematurely (e.g. if one holder of a share=
d_future requests cancellation when others wish to continue)</div>
<div><br></div><div>I suspect that the necessary infrastructure to support =
this is already present in many if not all implementations of std::promise;=
it looks like it would be trivial in libstdc++ and libc++, for example.</d=
iv>
<div><br></div><div>I see a few open questions:</div><div>- The bikeshed qu=
estion: what to name the method. Options include "canceled", &quo=
t;orphaned", or "ignored", or (with the meaning inverted) &q=
uot;has_future" or "viable". "abandoned" is tempti=
ng, but conflicts with the existing meaning of "abandon" in this =
context.</div>
<div>- Is there a need for an API to "detach" a promise, so that =
the computation is not abandoned even if the future is destroyed (e.g. beca=
use the computation is needed for its side effects rather than its result)?=
My hunch is that no, a computation like that will generally "know&quo=
t; it's being used that way, and so won't hold a promise in the fir=
st place, much less poll it for cancellation.</div>
<div>- Is there a need for a weak_future, representing a sort of "oppo=
rtunistic" consumer whose existence does not prevent the producer from=
terminating early?</div><div><br></div><div>Does this seem like a viable e=
xtension?</div>
</div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c2e8f06963b804ff05cdf8--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 25 Jul 2014 17:06:04 -0400
Raw View
--001a11c34cc2f890f404ff0af036
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 25, 2014 at 10:58 AM, 'Geoffrey Romer' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> Hi-
>
> It seems to me that it should be fairly straightforward to extend
> std::promise with a method that reports whether its state is shared with
> any "asynchronous return objects" (e.g. future, shared_future). This is
> valuable because it would enable the holder of a std::promise to terminate
> its work early if it knows that nobody will be able to access the result
> (e.g. if the work was initiated speculatively, or was canceled due to user
> intervention or a consumer-side timeout).
>
> I suspect that the necessary infrastructure to support this is already
> present in many if not all implementations of std::promise; it looks like
> it would be trivial in libstdc++ and libc++, for example.
>
>
I have an experimental non-allocating promise/future, and it would be
trivial there as well.
> I see a few open questions:
> - The bikeshed question: what to name the method. Options include
> "canceled", "orphaned", or "ignored", or (with the meaning inverted)
> "has_future" or "viable". "abandoned" is tempting, but conflicts with the
> existing meaning of "abandon" in this context.
>
Always bikesheds.
> - Is there a need for an API to "detach" a promise, so that the
> computation is not abandoned even if the future is destroyed (e.g. because
> the computation is needed for its side effects rather than its result)? My
> hunch is that no, a computation like that will generally "know" it's being
> used that way, and so won't hold a promise in the first place, much less
> poll it for cancellation.
>
Hadn't considered that - it could always be added later, I think.
> - Is there a need for a weak_future, representing a sort of
> "opportunistic" consumer whose existence does not prevent the producer from
> terminating early?
>
too complicated? Seems like too much if it requires a separate class.
>
> Does this seem like a viable extension?
>
>
I think so. In fact, I brought up the same idea very briefly at one of the
standard's meetings with a few people. Herb was one, forget who else. It
seemed reasonable to them at the time.
Tony
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c34cc2f890f404ff0af036
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Jul 25, 2014 at 10:58 AM, 'Geoffrey Romer'=
via ISO C++ Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"m=
ailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org<=
/a>></span> wrote:<br>
<div><div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi-<div><br></div><=
div>It seems to me that it should be fairly straightforward to extend std::=
promise with a method that reports whether its state is shared with any &qu=
ot;asynchronous return objects" (e.g. future, shared_future). This is =
valuable because it would enable the holder of a std::promise to terminate =
its work early if it knows that nobody will be able to access the result (e=
..g. if the work was initiated speculatively, or was canceled due to user in=
tervention or a consumer-side timeout).=C2=A0</div>
<div><br></div><div>I suspect that the necessary infrastructure to support =
this is already present in many if not all implementations of std::promise;=
it looks like it would be trivial in libstdc++ and libc++, for example.</d=
iv>
<div><br></div></div></blockquote><div><br></div><div>I have an experimenta=
l non-allocating promise/future, and it would be trivial there as well.<br>=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><div></div><div>I see a few open questions:</div><div>- Th=
e bikeshed question: what to name the method. Options include "cancele=
d", "orphaned", or "ignored", or (with the meaning=
inverted) "has_future" or "viable". "abandoned&qu=
ot; is tempting, but conflicts with the existing meaning of "abandon&q=
uot; in this context.</div>
</div></blockquote><div><br></div><div>Always bikesheds.<br>=C2=A0<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">
<div>- Is there a need for an API to "detach" a promise, so that =
the computation is not abandoned even if the future is destroyed (e.g. beca=
use the computation is needed for its side effects rather than its result)?=
My hunch is that no, a computation like that will generally "know&quo=
t; it's being used that way, and so won't hold a promise in the fir=
st place, much less poll it for cancellation.</div>
</div></blockquote><div><br></div><div>Hadn't considered that - it coul=
d always be added later, I think.<br>=C2=A0<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">
<div dir=3D"ltr">
<div>- Is there a need for a weak_future, representing a sort of "oppo=
rtunistic" consumer whose existence does not prevent the producer from=
terminating early?</div></div></blockquote><div><br></div><div>too complic=
ated?=C2=A0 Seems like too much if it requires a separate class.<br>
=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div><br></div><div>Does this seem like a viable extension?</div><=
span class=3D""><font color=3D"#888888">
</font></span></div><span class=3D""><font color=3D"#888888">
<p></p>
</font></span></blockquote><div><br></div><div>I think so.=C2=A0 In fact, I=
brought up the same idea very briefly at one of the standard's meeting=
s with a few people.=C2=A0 Herb was one, forget who else.=C2=A0 It seemed r=
easonable to them at the time.<br>
<br><br></div><div>Tony<br><br></div></div><br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c34cc2f890f404ff0af036--
.
Author: "'Geoffrey Romer' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Mon, 29 Sep 2014 22:16:39 -0700
Raw View
--001a11c30308f92cf40504417c7e
Content-Type: text/plain; charset=UTF-8
I started trying to write this up for Urbana, and I realized this API isn't
quite right. It's not enough to be able to poll for cancellation; in
general you want to be able to wait for cancellation (obviously via
something like when_any or at least wait_for). So I think the API should be
something more like a std::future<void> than a bool, but that means the
implementation is no longer trivially simple, and the proposal is no longer
a slam-dunk. I think it's still sound, but it requires more investigation
than I'm going to have time for in the next couple weeks.
On Jul 25, 2014 2:06 PM, "Tony V E" <tvaneerd@gmail.com> wrote:
> On Fri, Jul 25, 2014 at 10:58 AM, 'Geoffrey Romer' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>> Hi-
>>
>> It seems to me that it should be fairly straightforward to extend
>> std::promise with a method that reports whether its state is shared with
>> any "asynchronous return objects" (e.g. future, shared_future). This is
>> valuable because it would enable the holder of a std::promise to terminate
>> its work early if it knows that nobody will be able to access the result
>> (e.g. if the work was initiated speculatively, or was canceled due to user
>> intervention or a consumer-side timeout).
>>
>> I suspect that the necessary infrastructure to support this is already
>> present in many if not all implementations of std::promise; it looks like
>> it would be trivial in libstdc++ and libc++, for example.
>>
>>
> I have an experimental non-allocating promise/future, and it would be
> trivial there as well.
>
>
>> I see a few open questions:
>> - The bikeshed question: what to name the method. Options include
>> "canceled", "orphaned", or "ignored", or (with the meaning inverted)
>> "has_future" or "viable". "abandoned" is tempting, but conflicts with the
>> existing meaning of "abandon" in this context.
>>
>
> Always bikesheds.
>
>
>> - Is there a need for an API to "detach" a promise, so that the
>> computation is not abandoned even if the future is destroyed (e.g. because
>> the computation is needed for its side effects rather than its result)? My
>> hunch is that no, a computation like that will generally "know" it's being
>> used that way, and so won't hold a promise in the first place, much less
>> poll it for cancellation.
>>
>
> Hadn't considered that - it could always be added later, I think.
>
>
>> - Is there a need for a weak_future, representing a sort of
>> "opportunistic" consumer whose existence does not prevent the producer from
>> terminating early?
>>
>
> too complicated? Seems like too much if it requires a separate class.
>
>
>>
>> Does this seem like a viable extension?
>>
>>
> I think so. In fact, I brought up the same idea very briefly at one of
> the standard's meetings with a few people. Herb was one, forget who else.
> It seemed reasonable to them at the time.
>
>
> Tony
>
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c30308f92cf40504417c7e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">I started trying to write this up for Urbana, and I realized=
this API isn't quite right. It's not enough to be able to poll for=
cancellation; in general you want to be able to wait for cancellation (obv=
iously via something like when_any or at least wait_for). So I think the AP=
I should be something more like a std::future<void> than a bool, but =
that means the implementation is no longer trivially simple, and the propos=
al is no longer a slam-dunk. I think it's still sound, but it requires =
more investigation than I'm going to have time for in the next couple w=
eeks.</p>
<div class=3D"gmail_quote">On Jul 25, 2014 2:06 PM, "Tony V E" &l=
t;<a href=3D"mailto:tvaneerd@gmail.com">tvaneerd@gmail.com</a>> wrote:<b=
r type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On F=
ri, Jul 25, 2014 at 10:58 AM, 'Geoffrey Romer' via ISO C++ Standard=
- Future Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@i=
socpp.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:=
<br>
<div><div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi-<div><br></div><=
div>It seems to me that it should be fairly straightforward to extend std::=
promise with a method that reports whether its state is shared with any &qu=
ot;asynchronous return objects" (e.g. future, shared_future). This is =
valuable because it would enable the holder of a std::promise to terminate =
its work early if it knows that nobody will be able to access the result (e=
..g. if the work was initiated speculatively, or was canceled due to user in=
tervention or a consumer-side timeout).=C2=A0</div>
<div><br></div><div>I suspect that the necessary infrastructure to support =
this is already present in many if not all implementations of std::promise;=
it looks like it would be trivial in libstdc++ and libc++, for example.</d=
iv>
<div><br></div></div></blockquote><div><br></div><div>I have an experimenta=
l non-allocating promise/future, and it would be trivial there as well.<br>=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><div></div><div>I see a few open questions:</div><div>- Th=
e bikeshed question: what to name the method. Options include "cancele=
d", "orphaned", or "ignored", or (with the meaning=
inverted) "has_future" or "viable". "abandoned&qu=
ot; is tempting, but conflicts with the existing meaning of "abandon&q=
uot; in this context.</div>
</div></blockquote><div><br></div><div>Always bikesheds.<br>=C2=A0<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">
<div>- Is there a need for an API to "detach" a promise, so that =
the computation is not abandoned even if the future is destroyed (e.g. beca=
use the computation is needed for its side effects rather than its result)?=
My hunch is that no, a computation like that will generally "know&quo=
t; it's being used that way, and so won't hold a promise in the fir=
st place, much less poll it for cancellation.</div>
</div></blockquote><div><br></div><div>Hadn't considered that - it coul=
d always be added later, I think.<br>=C2=A0<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">
<div dir=3D"ltr">
<div>- Is there a need for a weak_future, representing a sort of "oppo=
rtunistic" consumer whose existence does not prevent the producer from=
terminating early?</div></div></blockquote><div><br></div><div>too complic=
ated?=C2=A0 Seems like too much if it requires a separate class.<br>
=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div><br></div><div>Does this seem like a viable extension?</div><=
span><font color=3D"#888888">
</font></span></div><span><font color=3D"#888888">
<p></p>
</font></span></blockquote><div><br></div><div>I think so.=C2=A0 In fact, I=
brought up the same idea very briefly at one of the standard's meeting=
s with a few people.=C2=A0 Herb was one, forget who else.=C2=A0 It seemed r=
easonable to them at the time.<br>
<br><br></div><div>Tony<br><br></div></div><br></div></div></div></div>
<p></p>
-- <br>
<br>
--- <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@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c30308f92cf40504417c7e--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 30 Sep 2014 14:33:27 +0800
Raw View
--Apple-Mail=_91288EE4-3123-4214-86D2-96A65CC51A3C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-30, at 1:16 PM, 'Geoffrey Romer' via ISO C++ Standard - Future P=
roposals <std-proposals@isocpp.org> wrote:
> I started trying to write this up for Urbana, and I realized this API isn=
't quite right. It's not enough to be able to poll for cancellation; in gen=
eral you want to be able to wait for cancellation (obviously via something =
like when_any or at least wait_for). So I think the API should be something=
more like a std::future<void> than a bool, but that means the implementati=
on is no longer trivially simple, and the proposal is no longer a slam-dunk=
.. I think it's still sound, but it requires more investigation than I'm goi=
ng to have time for in the next couple weeks.
>=20
Sounds useful, hope you can finish it.
I was also thinking about this since my class qualification proposal touche=
s on async. My thought was that a "hard" cancellation protocol would have t=
o be based on signal handlers (pthread_kill) or the like. Those disturb any=
ongoing wait, at which point a poll is appropriate.
Without the handler and the poll, though, kill semantics are so hopelessly =
ugly that you might as well terminate the whole process. So, it seems that =
both complementary pieces are necessary.
There could be an automatic signal sent to the thread when the shared state=
subscription disappears, and the standard library could define the signal =
handler. It could be quite elegant.
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_91288EE4-3123-4214-86D2-96A65CC51A3C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09–30, at 1:16 PM, 'Geoffrey Romer' via ISO C++ Standard - Futu=
re Proposals <<a href=3D"mailto:std-proposals@isocpp.org">std-proposals@=
isocpp.org</a>> wrote:</div><blockquote type=3D"cite"><p dir=3D"ltr">I s=
tarted trying to write this up for Urbana, and I realized this API isn't qu=
ite right. It's not enough to be able to poll for cancellation; in general =
you want to be able to wait for cancellation (obviously via something like =
when_any or at least wait_for). So I think the API should be something more=
like a std::future<void> than a bool, but that means the implementat=
ion is no longer trivially simple, and the proposal is no longer a slam-dun=
k. I think it's still sound, but it requires more investigation than I'm go=
ing to have time for in the next couple weeks.</p></blockquote><div>Sounds =
useful, hope you can finish it.</div><div><br></div><div>I was also thinkin=
g about this since my class qualification proposal touches on async. My tho=
ught was that a “hard” cancellation protocol would have to be b=
ased on signal handlers (<font face=3D"Courier">pthread_kill</font>) or the=
like. Those disturb any ongoing wait, at which point a poll is appropriate=
..</div><div><br></div><div>Without the handler and the poll, though, kill s=
emantics are so hopelessly ugly that you might as well terminate the whole =
process. So, it seems that both complementary pieces are necessary.</div><d=
iv><br></div><div>There could be an automatic signal sent to the thread whe=
n the shared state subscription disappears, and the standard library could =
define the signal handler. It could be quite elegant.</div></div></body></h=
tml>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_91288EE4-3123-4214-86D2-96A65CC51A3C--
.