------=_Part_5278_1780819656.1444711740170
Content-Type: multipart/alternative;
 boundary="----=_Part_5279_691504223.1444711740170"

------=_Part_5279_691504223.1444711740170
Content-Type: text/plain; charset=UTF-8

I'd like to suggest alternatives to the futures API proposal:

`is_ready()` is inconsistent. We have `empty()`, `valid()`, etc. The API
call should be `ready()`, not `is_ready()`.

`when_any` is an ineffective function. The time complexity of checking each
future is O(N) for N futures even if only 1 is ready.

I propose an alternative to `when_any`, `select`. Select is consitent with
other languages (e.g., Go, which does concurrency much better than C++ at
the moment.)

In order to use select one or more `std::futures_handler<int>` is required:

`
void baz()
{
  std::vector< std::future<int> > foo;
  std::vector< std::future<float> > bar;

  std::futures_handler<int> handle(foo.begin(), foo.end(),
[](std::future<int> i) { qaz(i); });
  std::futures_handler<float> handle2(bar.begin(), bar.end(), [] (
std::future<int> i) { raz(i); });

  while (!handle.done() || !handle2.done()) { std::select(handle, handle2);
}

}

....
`
This can provide an O(1) solution instead of O(N). Maybe it would be
possible for a `futures_handler` to take ownership of the futures, comments?

--

---
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/.

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

<div dir=3D"ltr">I&#39;d like to suggest alternatives to the futures API pr=
oposal:<br><br>`is_ready()` is inconsistent. We have `empty()`, `valid()`, =
etc. The API call should be `ready()`, not `is_ready()`.<br><br>`when_any` =
is an ineffective function. The time complexity of checking each future is =
O(N) for N futures even if only 1 is ready.<br><br>I propose an alternative=
 to `when_any`, `select`. Select is consitent with other languages (e.g., G=
o, which does concurrency much better than C++ at the moment.)<br><br>In or=
der to use select one or more `std::futures_handler&lt;int&gt;` is required=
:<br><br>`<br>void baz()<br>{<br>=C2=A0 std::vector&lt; std::future&lt;int&=
gt; &gt; foo;<br>=C2=A0 std::vector&lt; std::future&lt;float&gt; &gt; bar;<=
br><br>=C2=A0 std::futures_handler&lt;int&gt; handle(foo.begin(), foo.end()=
, [](std::future&lt;int&gt; i) { qaz(i); });<br>=C2=A0 std::futures_handler=
&lt;float&gt; handle2(bar.begin(), bar.end(), [] ( std::future&lt;int&gt; i=
) { raz(i); });<br><br>=C2=A0 while (!handle.done() || !handle2.done()) { s=
td::select(handle, handle2); }<br><br>}<br><br>...<br>`<br>This can provide=
 an O(1) solution instead of O(N). Maybe it would be possible for a `future=
s_handler` to take ownership of the futures, comments?<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

------=_Part_5279_691504223.1444711740170--
------=_Part_5278_1780819656.1444711740170--

.

------=_Part_5311_717349673.1444711912113
Content-Type: multipart/alternative;
 boundary="----=_Part_5312_597500811.1444711912114"

------=_Part_5312_597500811.1444711912114
Content-Type: text/plain; charset=UTF-8

I made a few mistakes in that code, sorry about that. I'm a bit tired at
the moment. I think the general idea should be clear though.

On Tuesday, October 13, 2015 at 12:49:00 AM UTC-4, Ryan Nicholl wrote:
>
> I'd like to suggest alternatives to the futures API proposal:
>
> `is_ready()` is inconsistent. We have `empty()`, `valid()`, etc. The API
> call should be `ready()`, not `is_ready()`.
>
> `when_any` is an ineffective function. The time complexity of checking
> each future is O(N) for N futures even if only 1 is ready.
>
> I propose an alternative to `when_any`, `select`. Select is consitent with
> other languages (e.g., Go, which does concurrency much better than C++ at
> the moment.)
>
> In order to use select one or more `std::futures_handler<int>` is required:
>
> `
> void baz()
> {
>   std::vector< std::future<int> > foo;
>   std::vector< std::future<float> > bar;
>
>   std::futures_handler<int> handle(foo.begin(), foo.end(),
> [](std::future<int> i) { qaz(i); });
>   std::futures_handler<float> handle2(bar.begin(), bar.end(), [] (
> std::future<int> i) { raz(i); });
>
>   while (!handle.done() || !handle2.done()) { std::select(handle,
> handle2); }
>
> }
>
> ...
> `
> This can provide an O(1) solution instead of O(N). Maybe it would be
> possible for a `futures_handler` to take ownership of the futures, comments?
>

--

---
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/.

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

<div dir=3D"ltr">I made a few mistakes in that code, sorry about that. I&#3=
9;m a bit tired at the moment. I think the general idea should be clear tho=
ugh.<br><br>On Tuesday, October 13, 2015 at 12:49:00 AM UTC-4, Ryan Nicholl=
 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">I&#39;=
d like to suggest alternatives to the futures API proposal:<br><br>`is_read=
y()` is inconsistent. We have `empty()`, `valid()`, etc. The API call shoul=
d be `ready()`, not `is_ready()`.<br><br>`when_any` is an ineffective funct=
ion. The time complexity of checking each future is O(N) for N futures even=
 if only 1 is ready.<br><br>I propose an alternative to `when_any`, `select=
`. Select is consitent with other languages (e.g., Go, which does concurren=
cy much better than C++ at the moment.)<br><br>In order to use select one o=
r more `std::futures_handler&lt;int&gt;` is required:<br><br>`<br>void baz(=
)<br>{<br>=C2=A0 std::vector&lt; std::future&lt;int&gt; &gt; foo;<br>=C2=A0=
 std::vector&lt; std::future&lt;float&gt; &gt; bar;<br><br>=C2=A0 std::futu=
res_handler&lt;int&gt; handle(foo.begin(), foo.end(), [](std::future&lt;int=
&gt; i) { qaz(i); });<br>=C2=A0 std::futures_handler&lt;float&gt; handle2(b=
ar.begin(), bar.end(), [] ( std::future&lt;int&gt; i) { raz(i); });<br><br>=
=C2=A0 while (!handle.done() || !handle2.done()) { std::select(handle, hand=
le2); }<br><br>}<br><br>...<br>`<br>This can provide an O(1) solution inste=
ad of O(N). Maybe it would be possible for a `futures_handler` to take owne=
rship of the futures, comments?<br></div></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

------=_Part_5312_597500811.1444711912114--
------=_Part_5311_717349673.1444711912113--

.

On 13/10/15 05:49, Ryan Nicholl wrote:
> I'd like to suggest alternatives to the futures API proposal:
>
> `is_ready()` is inconsistent. We have `empty()`, `valid()`, etc. The API
> call should be `ready()`, not `is_ready()`.

The name in the original std::future proposal for C++11 was is_ready(),
and implementations have been shipping with that name since then, as an
extension.

> `when_any` is an ineffective function. The time complexity of checking
> each future is O(N) for N futures even if only 1 is ready.

You don't need to check: that's the point. The future returned from
when_any is automatically ready when one of the futures is ready, and
the result holds the index of the future that became ready, so you don't
need to check.

auto f=std::experimental::when_any(f1,f2,f3);

auto res=f.get();

switch(res.index){
case 0:
   handle(std::get<0>(res.futures));
   break;
case 1:
   handle(std::get<1>(res.futures));
   break;
case 2:
   handle(std::get<2>(res.futures));
   break;
}

Anthony
--
Author of C++ Concurrency in Action     http://www.stdthread.co.uk/book/
just::thread C++11 thread library             http://www.stdthread.co.uk
Just Software Solutions Ltd       http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

--

---
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/.

.

On 2015-10-13 04:55, Anthony Williams wrote:
> On 13/10/15 05:49, Ryan Nicholl wrote:
>> I'd like to suggest alternatives to the futures API proposal:
>>
>> `is_ready()` is inconsistent. We have `empty()`, `valid()`, etc. The API
>> call should be `ready()`, not `is_ready()`.
>
> The name in the original std::future proposal for C++11 was is_ready(),
> and implementations have been shipping with that name since then, as an
> extension.

That doesn't preclude using the "good" name and, implementations that
have the old name retaining it as a synonym (deprecated) for
compatibility. Besides, are existing extensions going to be compatible
with the final accepted form anyway? (Note: I don't know, I haven't been
following this proposal closely. Point is, if they aren't, the
compatibility argument loses most of its effectiveness, and may even be
a reason in *favor* or making a change.)

--
Matthew

--

---
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/.

.

------=_Part_1296_1088859930.1444839827110
Content-Type: text/plain; charset=UTF-8

Really? Becuase I was reading the last numbered document on futures I could find. It seemed to suggest an alternate interpretation.

Anyway, when_any would still be O(n) because it requires reconstructing the list every time you call it. For this reason it remains O(n).

I will revise my suggestion a bit:

`
std::futures_handler<T>;
`
Constructor:
`futures_handler(Iterator begin, Iterator end)`
`
Methods:

`
bool ready() const // a future is ready
`

Select:
`
void std::select(my_hander1, handler1_callback, my_handler2, handler2_callback);
`

In order to speed it up, we can make futures_handler take ownership of the futures.
We can add size(), insert(), etc.

Member function:
`
std::future<T> next() // returns next ready future and removes it from the container, blocks otnerwise.`

Plus `try_next`. We could add `ready_begin()` and `ready_end()` as well. Comments?

--

---
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/.

------=_Part_1296_1088859930.1444839827110--

.

On 14/10/15 17:23, Ryan Nicholl wrote:
> Really? Becuase I was reading the last numbered document on futures I could find. It seemed to suggest an alternate interpretation.

Yes, really. The concurrency TS draft is
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4501.html

See the sections on when_any and when_any_result.

> Anyway, when_any would still be O(n) because it requires reconstructing the list every time you call it. For this reason it remains O(n).

Yes, constructing the list is O(n), as the n futures have to be moved
into the list. However, moving a future is cheap.

Also, I don't see people doing this repeatedly with the same set of
futures: this is typically going to be a one-off --- once the first
future is ready, do xyz.

If you want to do the same thing when each is ready, call .then on each
of them in turn to set up the continuations.

> void std::select(my_hander1, handler1_callback, my_handler2, handler2_callback);

What is your use case? What problem are you trying to solve?

You clearly feel this is a useful construct, but I'm not seeing what it
would be good for, so a more concrete example of a scenario where you
would like to use it would be helpful to me.

Anthony
--
Author of C++ Concurrency in Action     http://www.stdthread.co.uk/book/
just::thread C++11 thread library             http://www.stdthread.co.uk
Just Software Solutions Ltd       http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

--

---
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/.

.

------=_Part_7149_1388878493.1444841149688
Content-Type: text/plain; charset=UTF-8

I would rather have select because it offers finer control. For example, maybe I can't run the callbacks concurrently. If I used .then() it would create too many OS threads.

I suggest taking a look at the Google Go language, which has motivating exaamples for select.

A futures_handler is similar to a Go channel but futureified.

The syntax is easier to manage and leads to less bugs.

--

---
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/.

------=_Part_7149_1388878493.1444841149688--

.

------=_Part_1644_1442886494.1444841484802
Content-Type: text/plain; charset=UTF-8

Oh and moving a future is not cheap when you have ~50,000 pending socket reads. :)

--

---
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/.

------=_Part_1644_1442886494.1444841484802--

.

On 14/10/15 17:45, Ryan Nicholl wrote:
> I would rather have select because it offers finer control. For example, maybe I can't run the callbacks concurrently. If I used .then() it would create too many OS threads.

If you can't run your callbacks concurrently, you could use a mutex or
semaphore to limit the concurrency.

> I suggest taking a look at the Google Go language, which has motivating exaamples for select.
>
> A futures_handler is similar to a Go channel but futureified.

Have you got a concrete example in mind (even one in go)? I'm finding it
hard to understand what you're suggesting without a concrete example.

> The syntax is easier to manage and leads to less bugs.

At the moment, I don't understand your use case, so I can't judge that.

Anthony
--
Author of C++ Concurrency in Action     http://www.stdthread.co.uk/book/
just::thread C++11 thread library             http://www.stdthread.co.uk
Just Software Solutions Ltd       http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

--

---
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/.

.

On Wed, Oct 14, 2015 at 9:45 AM, Ryan Nicholl <r.p.nicholl@gmail.com> wrote:
> I would rather have select because it offers finer control. For example, maybe I can't run the callbacks concurrently. If I used .then() it would create too many OS threads.
>

Could you be more precise? .then() doesn't create any new threads, but
maybe you're assuming some code around .then() that would?

> I suggest taking a look at the Google Go language, which has motivating exaamples for select.

The same examples motivate when_any(). Granted, when_any() is somewhat
hard to use, but when_any() is also designed for use in a
non-garbage-collected language.

You can also build whatever you want on top of .then(). Try building
it, and show us the code.

> A futures_handler is similar to a Go channel but futureified.

Again, you need more precision here. I think what you're looking for
is a channel that yields the next ready future, something like Guava's
Futures.inCompletionOrder(). But once you have that, you don't need
select().

> Oh and moving a future is not cheap when you have ~50,000 pending socket reads. :)

Note that Go's select statement takes a static number of channels, so
it doesn't scale to 50k arguments either.

Jeffrey

--

---
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/.

.

------=_Part_3868_1815955209.1444842481181
Content-Type: text/plain; charset=UTF-8

First. I want to run only 8 callbacks at a time.
So I could perhaps place my futures into a futures handler, and have 8 threads do a select loop. I could have 50,000 readdy future<foo> BUT I also need another value (bar) to use them with baz(myfoo, mybar). 50,000 threads blocking on a shared_future or 8?

What if I want to process some callbacks before others? I could check high priority callbacks first with try select, etc.

--

---
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/.

------=_Part_3868_1815955209.1444842481181--

.

------=_Part_392_133817157.1444842737500
Content-Type: text/plain; charset=UTF-8

But when_any takes futures, not channels.

select is like Go's select. My understanding is one future, one value. somewhat inefficient perhaps? one futures_handler could have callbacks for many futures...

An alternate solution would be the introduction of std::channel<T> and promise<T>::get_channel().

I will provide a better code example this afternoon if possible.

--

---
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/.

------=_Part_392_133817157.1444842737500--

.

--047d7b4142c893db67052213d9d7
Content-Type: text/plain; charset=UTF-8

Yep, channels and futures are different things. If you want channels, don't
title your thread "Futures API". ;)

There is a need for a channels API, and adapters between it and the Futures
API. The channels api likely won't involve promises though, since those
only produce a single value.
On Oct 14, 2015 10:12 AM, "Ryan Nicholl" <r.p.nicholl@gmail.com> wrote:

> But when_any takes futures, not channels.
>
> select is like Go's select. My understanding is one future, one value.
> somewhat inefficient perhaps? one futures_handler could have callbacks for
> many futures...
>
> An alternate solution would be the introduction of std::channel<T> and
> promise<T>::get_channel().
>
> I will provide a better code example this afternoon if possible.
>
> --
>
> ---
> 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/.

--047d7b4142c893db67052213d9d7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Yep, channels and futures are different things. If you want =
channels, don&#39;t title your thread &quot;Futures API&quot;. ;)</p>
<p dir=3D"ltr">There is a need for a channels API, and adapters between it =
and the Futures API. The channels api likely won&#39;t involve promises tho=
ugh, since those only produce a single value.</p>
<div class=3D"gmail_quote">On Oct 14, 2015 10:12 AM, &quot;Ryan Nicholl&quo=
t; &lt;<a href=3D"mailto:r.p.nicholl@gmail.com">r.p.nicholl@gmail.com</a>&g=
t; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But when=
_any takes futures, not channels.<br>
<br>
select is like Go&#39;s select. My understanding is one future, one value. =
somewhat inefficient perhaps? one futures_handler could have callbacks for =
many futures...<br>
<br>
An alternate solution would be the introduction of std::channel&lt;T&gt; an=
d promise&lt;T&gt;::get_channel().<br>
<br>
I will provide a better code example this afternoon if possible.<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--047d7b4142c893db67052213d9d7--

.

On 10/14/2015 06:51 PM, Ryan Nicholl wrote:
> Oh and moving a future is not cheap when you have ~50,000 pending socket reads. :)

In which case you want to use Networking TS's io_context rather than
selecting on futures.

--

---
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/.

.

------=_Part_159_963826683.1444879772347
Content-Type: multipart/alternative;
 boundary="----=_Part_160_1589018932.1444879772347"

------=_Part_160_1589018932.1444879772347
Content-Type: text/plain; charset=UTF-8

Here is a more complete and concrete explanation.

The .then() method is problematic because it allows the "then" handler
function to be scheduled by the C++ runtime. This is problematic for
several reasons. One of the main reasons is references. If "foo my_foo;"
has a method that returns a "future<bar>" and I need to act on both the
state of that returned bar AND the state of my_foo, what do I do? With the
..then() method I must attach a reference to the my_foo object. This creates
a memory dependency. If my_foo is destructed after the future<bar>
completes and passes its value to the then() callback the reference will be
invalid and a use-after-free error occurs. The "solution" to use a
shared_pointer OR wait on the bar within the context of my_foo.
Unfortunately, if I have 50,000 pending future<bar> operations, each
when_any loop will iterate 50,000 times., 50,000 the first, 49,999 the
second, virtually O(n^2) to complete all the callbacks. For N callbacks,
the time complexity is O(N^2) because it it N loops time the complexity of
when_any, which is O(N), and O(N)*O(N) = O(N^2). O(N^2) is not acceptable.
I could reduce the time complexity by using then, but if I do that I
introduce the shared pointer issue. Furthermore, the shared pointer is at
best, a kludge. What if I wanted to cancel all outstanding requests? For
example, I determine that the client has disconnected or is serving a DOS
attack. I no longer have any reason to compute the my_foo.baz(some_bar)
function. I can't do this if I used .then() without adding a flag argument
to the data structure of my_foo. Even so, the handlers would still run and
use up memory for a while, and destruction of foo would be delayed.
Avoiding the usage of garbage collection, memory reference management and
shared_pointers in favour of RAII instead merits the usage of a when_any
style interface. However, when_any is not as fast. There should be no
reason that I have to pick one or the other. With select I suffer neither
the drawbacks of .then() nor when_any().

My suggestion of std::futures_handler is effectively a channel. There is no
reason that a futures handler could not also double as a channel type
interface.

In fact, let me revise the name:

template <typename T>
class std::future_channel
{
private:
  ...
public:
  future_channel();
  template <typename It>
  future_channel(It begin, It end);

  void insert(std::future<T> f);
  void insert(T t);

  template <typename T2>
  void insert_exception(T2 ex);

  bool ready() const;
  bool empty() const;

  size_t size() const;



  T get();
  std::future<T> next();

};


std::select would allow you to wait on multiple channels in O(C), where C
is the number of channels (not the number of attached futures!)

This provides a complete unification of I/O. io_service and other remnants
of boost.asio are not needed using this futures API. The networking
functions can use futures, and all will be consistent and well. Or you
could adopt the boost interface without thought and turn C++ into a
cluttered and bloated language.

On Wednesday, October 14, 2015 at 2:07:42 PM UTC-4, Bjorn Reese wrote:
>
> On 10/14/2015 06:51 PM, Ryan Nicholl wrote:
> > Oh and moving a future is not cheap when you have ~50,000 pending socket
> reads. :)
>
> In which case you want to use Networking TS's io_context rather than
> selecting on futures.
>
>

--

---
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/.

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

<div dir=3D"ltr"><div><div>Here is a more complete and concrete explanation=
..<br><br>The .then()=20
method is problematic because it allows the &quot;then&quot; handler functi=
on to=20
be scheduled by the C++ runtime. This is problematic for several=20
reasons. One of the main reasons is references. If &quot;foo my_foo;&quot; =
has a=20
method that returns a &quot;future&lt;bar&gt;&quot; and I need to act on bo=
th the=20
state of that returned bar AND the state of my_foo, what do I do? With=20
the .then() method I must attach a reference to the my_foo object. This=20
creates a memory dependency. If my_foo is destructed after the=20
future&lt;bar&gt; completes and passes its value to the then() callback=20
the reference will be invalid and a use-after-free error occurs. The=20
&quot;solution&quot; to use a shared_pointer OR wait on the bar within the =
context
 of my_foo. Unfortunately, if I have 50,000 pending future&lt;bar&gt;=20
operations, each when_any loop will iterate 50,000 times., 50,000 the=20
first, 49,999 the second, virtually O(n^2) to complete all the=20
callbacks. For N callbacks, the time complexity is O(N^2) because it it N
 loops time the complexity of when_any, which is O(N), and O(N)*O(N) =3D=20
O(N^2). O(N^2) is not acceptable. I could reduce the time complexity by=20
using then, but if I do that I introduce the shared pointer issue.=20
Furthermore, the shared pointer is at best, a kludge. What if I wanted=20
to cancel all outstanding requests? For example, I determine that the=20
client has disconnected or is serving a DOS attack. I no longer have any
 reason to compute the my_foo.baz(some_bar) function. I can&#39;t do this i=
f
 I used .then() without adding a flag argument to the data structure of=20
my_foo. Even so, the handlers would still run and use up memory for a=20
while, and destruction of foo would be delayed. <br>Avoiding the usage=20
of garbage collection, memory reference management and shared_pointers=20
in favour of RAII instead merits the usage of a when_any style=20
interface. However, when_any is not as fast. There should be no reason=20
that I have to pick one or the other. With select I suffer neither the=20
drawbacks of .then() nor when_any().<br><br>My suggestion of=20
std::futures_handler is effectively a channel. There is no reason that a
 futures handler could not also double as a channel type interface.<br><br>=
In fact, let me revise the name:<br><br><div style=3D"background-color:rgb(=
250,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:=
1px;word-wrap:break-word"><code><div><span style=3D"color:rgb(0,0,136)">tem=
plate</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:r=
gb(102,102,0)">&lt;</span><span style=3D"color:rgb(0,0,136)">typename</span=
><span style=3D"color:rgb(0,0,0)"> T</span><span style=3D"color:rgb(102,102=
,0)">&gt;</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"=
color:rgb(0,0,136)">class</span><span style=3D"color:rgb(0,0,0)"> std</span=
><span style=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0=
,0)">future_channel<br></span><span style=3D"color:rgb(102,102,0)">{</span>=
<span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(0,0,13=
6)">private</span><span style=3D"color:rgb(102,102,0)">:</span><span style=
=3D"color:rgb(0,0,0)"><br>=C2=A0 </span><span style=3D"color:rgb(102,102,0)=
">...</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"colo=
r:rgb(0,0,136)">public</span><span style=3D"color:rgb(102,102,0)">:</span><=
span style=3D"color:rgb(0,0,0)"><br>=C2=A0 future_channel</span><span style=
=3D"color:rgb(102,102,0)">();</span><span style=3D"color:rgb(0,0,0)"><br>=
=C2=A0 </span><span style=3D"color:rgb(0,0,136)">template</span><span style=
=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">&lt;</sp=
an><span style=3D"color:rgb(0,0,136)">typename</span><span style=3D"color:r=
gb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">It</span><span styl=
e=3D"color:rgb(102,102,0)">&gt;</span><span style=3D"color:rgb(0,0,0)"><br>=
=C2=A0 future_channel</span><span style=3D"color:rgb(102,102,0)">(</span><s=
pan style=3D"color:rgb(102,0,102)">It</span><span style=3D"color:rgb(0,0,0)=
"> </span><span style=3D"color:rgb(0,0,136)">begin</span><span style=3D"col=
or:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> </span><span s=
tyle=3D"color:rgb(102,0,102)">It</span><span style=3D"color:rgb(0,0,0)"> </=
span><span style=3D"color:rgb(0,0,136)">end</span><span style=3D"color:rgb(=
102,102,0)">);</span><span style=3D"color:rgb(0,0,0)"><br><br>=C2=A0 </span=
><span style=3D"color:rgb(0,0,136)">void</span><span style=3D"color:rgb(0,0=
,0)"> insert</span><span style=3D"color:rgb(102,102,0)">(</span><span style=
=3D"color:rgb(0,0,0)">std</span><span style=3D"color:rgb(102,102,0)">::</sp=
an><span style=3D"color:rgb(0,0,0)">future</span><span style=3D"color:rgb(1=
02,102,0)">&lt;</span><span style=3D"color:rgb(0,0,0)">T</span><span style=
=3D"color:rgb(102,102,0)">&gt;</span><span style=3D"color:rgb(0,0,0)"> f</s=
pan><span style=3D"color:rgb(102,102,0)">);</span><span style=3D"color:rgb(=
0,0,0)"><br></span><code><span style=3D"color:rgb(0,0,0)">=C2=A0 </span><sp=
an style=3D"color:rgb(0,0,136)">void</span><span style=3D"color:rgb(0,0,0)"=
> insert</span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"=
color:rgb(0,0,0)">T t</span><span style=3D"color:rgb(102,102,0)">);</span><=
span style=3D"color:rgb(0,0,0)"><br><br>=C2=A0 template &lt;typename T2&gt;=
<br>=C2=A0 void insert_exception(T2 ex);<br><br>=C2=A0 bool ready() const;<=
br>=C2=A0 bool empty() const;<br><br>=C2=A0 size_t size() const;<br><br><br=
><br>=C2=A0 T get();<br></span></code></div><div><code><span style=3D"color=
:rgb(0,0,0)">=C2=A0 std::future&lt;T&gt; next();<br></span></code></div><di=
v><code><span style=3D"color:rgb(0,0,0)"><br></span></code><span style=3D"c=
olor:rgb(102,102,0)">};</span><span style=3D"color:rgb(0,0,0)"><br></span><=
/div></code></div><br><br></div>std::select
 would allow you to wait on multiple channels in O(C), where C is the=20
number of channels (not the number of attached futures!)<br><br>This provid=
es a complete unification of I/O. io_service and other remnants of boost.as=
io are not needed using this futures API. The networking functions can use =
futures, and all will be consistent and well. Or you could adopt the boost =
interface without thought and turn C++ into a cluttered and bloated languag=
e.<br></div><br>On Wednesday, October 14, 2015 at 2:07:42 PM UTC-4, Bjorn R=
eese wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 10/14/2015 06:51=
 PM, Ryan Nicholl wrote:
<br>&gt; Oh and moving a future is not cheap when you have ~50,000 pending =
socket reads. :)
<br>
<br>In which case you want to use Networking TS&#39;s io_context rather tha=
n
<br>selecting on futures.
<br>
<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

------=_Part_160_1589018932.1444879772347--
------=_Part_159_963826683.1444879772347--

.

This is a multi-part message in MIME format.
--------------010208090804070008080301
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 14/10/15 19:04, 'Jeffrey Yasskin' via ISO C++ Standard - Future=20
Proposals a =C3=A9crit :
> On Wed, Oct 14, 2015 at 9:45 AM, Ryan Nicholl <r.p.nicholl@gmail.com> wro=
te:
>> I would rather have select because it offers finer control. For example,=
 maybe I can't run the callbacks concurrently. If I used .then() it would c=
reate too many OS threads.
>>
> Could you be more precise? .then() doesn't create any new threads, but
> maybe you're assuming some code around .then() that would?
Maybe the Boost.Thread code :(

I agree that the Concurrent TS, doesn't specifies on which thread the=20
continuation is executed.

"When the object's shared state is ready, the continuation=20
|/INVOKE/(/DECAY_COPY/(std::forward<F>(func)), std::move(*this))| is=20
called on an unspecified thread of execution with the call to=20
|/DECAY_COPY/()| being evaluated in the thread that called |then|. "

Boost.Thread specification is different (based on an old version of the=20
::then() / async() proposal (an will create a new thread in some cases).
This old proposal had overloads for

     then(launch_policy, Continuation)
     then(Continuation)
     then(Executor, Continuation)

The behavior depends on the explicit launch_policy or Executor parameter=20
and the policy used to create the parent future when there is no such=20
parameter.

The current TS has only the second prototype, and the user can package a=20
specific behavior, e.g. wrapping an executor and a continuation, a=20
continuation can be executed in a specific executor. Or can wrap it to=20
call to async.

However the current TS specification doesn't says what happens when the=20
future is created with async(launch_policy::deferred, Cont) because the=20
experimental::future cannot be created by async, as there is no=20
experimental::async.

In the old proposal the deferred future would never be ready except if=20
::then() calls to ::wait().

Summary: boost::future and std::experimental::future behaves quite=20
differently for the time being. This could change in a near future.

Vicente

--=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/.

--------------010208090804070008080301
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 14/10/15 19:04, 'Jeffrey Yasskin'
      via ISO C++ Standard - Future Proposals a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
cite=3D"mid:CANh-dXk81D+MFrXWszS6ym0xhNtM+GD+uZf9d+wThe=3DoLA-nZw@mail.gmai=
l.com"
      type=3D"cite">
      <pre wrap=3D"">On Wed, Oct 14, 2015 at 9:45 AM, Ryan Nicholl <a class=
=3D"moz-txt-link-rfc2396E" href=3D"mailto:r.p.nicholl@gmail.com">&lt;r.p.ni=
choll@gmail.com&gt;</a> wrote:
</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">I would rather have select because it offers finer c=
ontrol. For example, maybe I can't run the callbacks concurrently. If I use=
d .then() it would create too many OS threads.

</pre>
      </blockquote>
      <pre wrap=3D"">
Could you be more precise? .then() doesn't create any new threads, but
maybe you're assuming some code around .then() that would?</pre>
    </blockquote>
    Maybe the Boost.Thread code :(<br>
    <br>
    I agree that the Concurrent TS, doesn't specifies on which thread
    the continuation is executed.<br>
    <br>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8=
">
    "When the object's shared state is ready, the continuation <code><em>IN=
VOKE</em>(<em>DECAY_COPY</em>(std::forward&lt;F&gt;(func)),
      std::move(*this))</code> is called on an unspecified thread of
    execution with the call to <code><em>DECAY_COPY</em>()</code> being
    evaluated in the thread that called <code>then</code>. "<br>
    <br>
    Boost.Thread specification is different (based on an old version of
    the ::then() / async() proposal (an will create a new thread in some
    cases).<br>
    This old proposal had overloads for <br>
    <br>
    =C2=A0=C2=A0=C2=A0 then(launch_policy, Continuation)<br>
    =C2=A0=C2=A0=C2=A0 then(Continuation)<br>
    =C2=A0=C2=A0=C2=A0 then(Executor, Continuation)<br>
    <br>
    The behavior depends on the explicit launch_policy or Executor
    parameter and the policy used to create the parent future when there
    is no such parameter.<br>
    <br>
    The current TS has only the second prototype, and the user can
    package a specific behavior, e.g. wrapping an executor and a
    continuation, a continuation can be executed in a specific executor.
    Or can wrap it to call to async. <br>
    <br>
    However the current TS specification doesn't says what happens when
    the future is created with async(launch_policy::deferred, Cont)
    because the experimental::future cannot be created by async, as
    there is no experimental::async.<br>
    <br>
    In the old proposal the deferred future would never be ready except
    if ::then() calls to ::wait().<br>
    <br>
    Summary: boost::future and std::experimental::future behaves quite
    differently for the time being. This could change in a near future.<br>
    <br>
    Vicente<br>
    <br>
  </body>
</html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--------------010208090804070008080301--

.