------=_Part_4124_1435010570.1476224369111
Content-Type: multipart/alternative;
 boundary="----=_Part_4125_2105651389.1476224369111"

------=_Part_4125_2105651389.1476224369111
Content-Type: text/plain; charset=UTF-8

Hello,

Has there been an proposal for a channel's class in C++?

I have written a basic implementation and proposal and am looking for
feedback about usefulness. It does have one glaring feature missing which
is the 'select' or 'alt' blocks.

https://bitbucket.org/linuxuser27/c-channel

Thanks,
arr

--
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/40eec918-efff-431f-8624-c69bcf6f0dcb%40isocpp.org.

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

<div dir=3D"ltr">Hello,<div><br></div><div>Has there been an proposal for a=
 channel&#39;s class in C++?</div><div><br></div><div>I have written a basi=
c implementation and proposal and am looking for feedback about usefulness.=
 It does have one glaring feature missing which is the &#39;select&#39; or =
&#39;alt&#39; blocks.</div><div><br></div><div>https://bitbucket.org/linuxu=
ser27/c-channel<br></div><div><br></div><div>Thanks,</div><div>arr</div></d=
iv>

<p></p>

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

------=_Part_4125_2105651389.1476224369111--

------=_Part_4124_1435010570.1476224369111--

.

------=_Part_1118_1770827946.1476256606079
Content-Type: multipart/alternative;
 boundary="----=_Part_1119_1993866002.1476256606079"

------=_Part_1119_1993866002.1476256606079
Content-Type: text/plain; charset=UTF-8

How is this compare to Boot Fiber channels and John Bandela's Channels
(cppcon '16)?

--
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/ea861d30-46aa-45a2-a84e-75aae43424e3%40isocpp.org.

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

<div dir=3D"ltr"><div>How is this=C2=A0compare to Boot=C2=A0Fiber channels =
and John Bandela&#39;s Channels (cppcon &#39;16)? </div><div><br></div></di=
v>

<p></p>

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

------=_Part_1119_1993866002.1476256606079--

------=_Part_1118_1770827946.1476256606079--

.

--001a11449a2ebefe4d053ea84e8e
Content-Type: text/plain; charset=UTF-8

2016-10-12 0:19 GMT+02:00 Aaron R Robinson <linuxuser27@gmail.com>:

> I have written a basic implementation and proposal and am looking for
> feedback about usefulness. It does have one glaring feature missing which
> is the 'select' or 'alt' blocks.
>
> https://bitbucket.org/linuxuser27/c-channel
>
>
I don't have allot of mileage with multi-threaded applications but there's
something obvious that I'm missing in the proposal:
- Channel is bidirectional only. I would expect an additional producer
channel that would have a make_consumer member function enforcing single
producer multiple consumers pattern (not certain if multiple producers
single consumer would also be useful).

Since channel is a really basic building block nice to have feature would
be:
- Channel is using a single communication type so for bidirectional channel
a custom structure would have to be of a single type even if request and
response differ unless variant or any would be used. It would be a nice to
have feature to support this internally but since this functionality can be
added as a derived class this is not as important.

Future/promise pair can forward result or exceptions. Was that considered
for channels as well?

Regards,
Domen

--
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/CAKgx6BJsFo%3Dayj2QuH%2BnMniyTiuFNjpOPHNHGBZErx8KXSE3Yw%40mail.gmail.com.

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

<div dir=3D"ltr">2016-10-12 0:19 GMT+02:00 Aaron R Robinson <span dir=3D"lt=
r">&lt;<a href=3D"mailto:linuxuser27@gmail.com" target=3D"_blank">linuxuser=
27@gmail.com</a>&gt;</span>:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><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"><div>I have writ=
ten a basic implementation and proposal and am looking for feedback about u=
sefulness. It does have one glaring feature missing which is the &#39;selec=
t&#39; or &#39;alt&#39; blocks.</div><div><br></div><div><a href=3D"https:/=
/bitbucket.org/linuxuser27/c-channel" target=3D"_blank">https://bitbucket.o=
rg/linuxuse<wbr>r27/c-channel</a><br></div><div><br></div></div></blockquot=
e><div><br></div><div>I don&#39;t have allot of mileage with multi-threaded=
 applications but there&#39;s something obvious that I&#39;m missing in the=
 proposal:<br></div><div>- Channel is bidirectional only. I would expect an=
 additional producer channel that would have a make_consumer member functio=
n enforcing single producer multiple consumers pattern (not certain if mult=
iple producers single consumer would also be useful).<br><br></div><div>Sin=
ce channel is a really basic building block nice to have feature would be:<=
br></div><div>- Channel is using a single communication type so for bidirec=
tional channel a custom structure would have to be of a single type even if=
 request and response differ unless variant or any would be used. It would =
be a nice to have feature to support this internally but since this functio=
nality can be added as a derived class this is not as important.<br><br></d=
iv><div>Future/promise pair can forward result or exceptions. Was that cons=
idered for channels as well?<br></div><div><br></div><div>Regards,<br></div=
><div>Domen<br></div></div><br></div></div>

<p></p>

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

--001a11449a2ebefe4d053ea84e8e--

.

------=_Part_402_149047935.1476338020189
Content-Type: multipart/alternative;
 boundary="----=_Part_403_1831693764.1476338020190"

------=_Part_403_1831693764.1476338020190
Content-Type: text/plain; charset=UTF-8

>> How is this compare to Boot Fiber channels and John Bandela's Channels
(cppcon '16)?

Great question. I have looked briefly at both and there are at least two
very clear distinctions.

For the Boost Fiber Channels (BFC), the proposed implementation is more
inline with implementations of channels as they are known outside of C++.
For instance, the BFC's implementation of channels are _not_
interchangable. Meaning one can either use an unbounded (i.e. non-blocking)
channel or a bounded (i.e. blocking) channel, but they are distinct ideas
and that decision must be made during design time. This really isn't
appropriate in the general sense and intent of channels - I am sure there
are cases where an explicit decision should be made, but not generally. The
BFC API surface also exposes calls that imply the underlying implementation
(i.e. push()/pop()) which isn't technically bad, but can potentially cause
confusion to people who have used channel in the more formal/traditional
implementations of Go, Limbo, and occam.

John Bandela's talk was quite convincing, but intermingled the
Promise/Future methodology with that of channels - which are two very
distinct approaches to concurrency. Promise/Future is more related to an
async solution where as channels are more specific to data-sharing
synchronization. I think channels can be leveraged to make async approaches
more natural, but channels are a more primitive concept that doesn't imply
async at all, but merely synchronization.

>> - Channel is bidirectional only. I would expect an additional producer
channel that would have a make_consumer member function enforcing single
producer multiple consumers pattern (not certain if multiple producers
single consumer would also be useful).

I don't quite understand this statement. I can say that channels do not and
should not have any concept of directionality - they are always
bidirectional. A thread given a channel can either read from it or write to
it and that is by-design. I can definitely see the potential benefit from a
wrapper class that enforces a single direction, but that would be an
extension to a fully bidirectional channel.

>> - Channel is using a single communication type so for bidirectional
channel a custom structure would have to be of a single type even if
request and response differ unless variant or any would be used. It would
be a nice to have feature to support this internally but since this
functionality can be added as a derived class this is not as important.

The appropriate approach here would be to either have a channel the
producer would read from and one it would write from since all the channel
is doing is synchronizing the transmission of data/state. Basically if the
following was done:

// Shared state
channel<int> ch;

// Producer
ch << 10;

int r;
ch >> r;

// Consumer
int r;
ch >> r;

There is a high probably that the consumer would never get 10, instead the
producer would extract the very value it inserted. This is not the intent
of channels as they are more inline with the concept of a stream that is
merely consumed as opposed to a TCP/IP like connection where a confirmation
occurs. That being said, your point about a derived or composed class that
enables this kind of functionality may definitely find use.

>> Future/promise pair can forward result or exceptions. Was that
considered for channels as well?
I mentioned this above with respect to John Bandela's talk. Promise/Future
approaches are solving a different problem where as channels are merely a
synchronization primitive.

arr

--
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/1d8188d1-1710-477f-8865-593bdf07259e%40isocpp.org.

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

<div dir=3D"ltr"><div>&gt;&gt; How is this compare to Boot Fiber channels a=
nd John Bandela&#39;s Channels (cppcon &#39;16)?</div><div><br></div><div>G=
reat question. I have looked briefly at both and there are at least two ver=
y clear distinctions.</div><div><br></div><div>For the Boost Fiber Channels=
 (BFC), the proposed implementation is more inline with implementations of =
channels as they are known outside of C++. For instance, the BFC&#39;s impl=
ementation of channels are _not_ interchangable. Meaning one can either use=
 an unbounded (i.e. non-blocking) channel or a bounded (i.e. blocking) chan=
nel, but they are distinct ideas and that decision must be made during desi=
gn time. This really isn&#39;t appropriate in the general sense and intent =
of channels - I am sure there are cases where an explicit decision should b=
e made, but not generally. The BFC API surface also exposes calls that impl=
y the underlying implementation (i.e. push()/pop()) which isn&#39;t technic=
ally bad, but can potentially cause confusion to people who have used chann=
el in the more formal/traditional implementations of Go, Limbo, and occam.<=
/div><div><br></div><div>John Bandela&#39;s talk was quite convincing, but =
intermingled the Promise/Future methodology with that of channels - which a=
re two very distinct approaches to concurrency. Promise/Future is more rela=
ted to an async solution where as channels are more specific to data-sharin=
g synchronization. I think channels can be leveraged to make async approach=
es more natural, but channels are a more primitive concept that doesn&#39;t=
 imply async at all, but merely synchronization.</div><div><br></div><div>&=
gt;&gt; - Channel is bidirectional only. I would expect an additional produ=
cer channel that would have a make_consumer member function enforcing singl=
e producer multiple consumers pattern (not certain if multiple producers si=
ngle consumer would also be useful).</div><div><br></div><div>I don&#39;t q=
uite understand this statement. I can say that channels do not and should n=
ot have any concept of directionality - they are always bidirectional. A th=
read given a channel can either read from it or write to it and that is by-=
design. I can definitely see the potential benefit from a wrapper class tha=
t enforces a single direction, but that would be an extension to a fully bi=
directional channel.</div><div><br></div><div>&gt;&gt; - Channel is using a=
 single communication type so for bidirectional channel a custom structure =
would have to be of a single type even if request and response differ unles=
s variant or any would be used. It would be a nice to have feature to suppo=
rt this internally but since this functionality can be added as a derived c=
lass this is not as important.</div><div><br></div><div>The appropriate app=
roach here would be to either have a channel the producer would read from a=
nd one it would write from since all the channel is doing is synchronizing =
the transmission of data/state. Basically if the following was done:</div><=
div><br></div><div>// Shared state</div><div>channel&lt;int&gt; ch;</div><d=
iv><br></div><div>// Producer</div><div>ch &lt;&lt; 10;</div><div><br></div=
><div>int r;</div><div>ch &gt;&gt; r;</div><div><br></div><div>// Consumer<=
/div><div>int r;</div><div>ch &gt;&gt; r;</div><div><br></div><div>There is=
 a high probably that the consumer would never get 10, instead the producer=
 would extract the very value it inserted. This is not the intent of channe=
ls as they are more inline with the concept of a stream that is merely cons=
umed as opposed to a TCP/IP like connection where a confirmation occurs. Th=
at being said, your point about a derived or composed class that enables th=
is kind of functionality may definitely find use.=C2=A0</div><div><br></div=
><div>&gt;&gt; Future/promise pair can forward result or exceptions. Was th=
at considered for channels as well?</div><div>I mentioned this above with r=
espect to John Bandela&#39;s talk. Promise/Future approaches are solving a =
different problem where as channels are merely a synchronization primitive.=
</div><div><br></div><div>arr</div></div>

<p></p>

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

------=_Part_403_1831693764.1476338020190--

------=_Part_402_149047935.1476338020189--

.

--001a114853188806cd053ec51a77
Content-Type: text/plain; charset=UTF-8

2016-10-13 7:53 GMT+02:00 Aaron R Robinson <linuxuser27@gmail.com>:

> >> How is this compare to Boot Fiber channels and John Bandela's Channels
> (cppcon '16)?
>


> For the Boost Fiber Channels (BFC), the proposed implementation is more
> inline with implementations of channels as they are known outside of C++.
>

channels of boost.fiber are not channels in the sense of GO channels - both
types in fact are queues.
unbounded_queue: stores unlimited items
bounded_queue: stores items only up to a maximum, any subsequent push
operations will block until some items have been removed

--
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/CA%2Bwfc1-a3-oJnGb0wtbsadm3stVwY5Jw%2BgNv6YU1bx-MRSWCXg%40mail.gmail.com.

--001a114853188806cd053ec51a77
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">2016=
-10-13 7:53 GMT+02:00 Aaron R Robinson <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:linuxuser27@gmail.com" target=3D"_blank">linuxuser27@gmail.com</a>&gt;<=
/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"><span class=3D""=
><div>&gt;&gt; How is this compare to Boot Fiber channels and John Bandela&=
#39;s Channels (cppcon &#39;16)?</div></span></div></blockquote><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>For the Boost Fi=
ber Channels (BFC), the proposed implementation is more inline with impleme=
ntations of channels as they are known outside of C++.</div></div></blockqu=
ote><div><br></div><div>channels of boost.fiber are not channels in the sen=
se of GO channels - both types in fact are queues.<br></div><div>unbounded_=
queue: stores unlimited items<br></div><div>bounded_queue: stores items onl=
y up to a maximum, any subsequent push operations will block until some ite=
ms have been removed<br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1-a3-oJnGb0wtbsadm3stVwY5Jw%2=
BgNv6YU1bx-MRSWCXg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1-a3-=
oJnGb0wtbsadm3stVwY5Jw%2BgNv6YU1bx-MRSWCXg%40mail.gmail.com</a>.<br />

--001a114853188806cd053ec51a77--

.

------=_Part_780_48511395.1476414983136
Content-Type: multipart/alternative;
 boundary="----=_Part_781_566544772.1476414983137"

------=_Part_781_566544772.1476414983137
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, October 13, 2016 at 1:39:26 PM UTC-7, Oliver Kowalke wrote:
>
> 2016-10-13 7:53 GMT+02:00 Aaron R Robinson <linux...@gmail.com=20
> <javascript:>>:
>
>> >> How is this compare to Boot Fiber channels and John Bandela's Channel=
s=20
>> (cppcon '16)?
>>
> =20
>
>> For the Boost Fiber Channels (BFC), the proposed implementation is more=
=20
>> inline with implementations of channels as they are known outside of C++=
..
>>
>
> channels of boost.fiber are not channels in the sense of GO channels -=20
> both types in fact are queues.
> unbounded_queue: stores unlimited items
> bounded_queue: stores items only up to a maximum, any subsequent push=20
> operations will block until some items have been removed
>

The code at=20
https://bitbucket.org/linuxuser27/c-channel/src/eb4b53d2764c010b95c02714e09=
5e149d8765929/channels.h
also implements merely a bounded queue, AFAICT, and not what Go means by=20
"channels".

I don't know whether Go-style channels are implementable in present-day=20
C++; you might need to get more coroutine-awareness in the language first=
=20
somehow (and in fact I would be pleasantly shocked if Gor's coroutines=20
proposal was anywhere close to aware enough).

I would think that a "C++-ish" channel should follow the same outline as=20
std::future/std::promise =E2=80=94 it should be uni-directional as requeste=
d by=20
Domen in this thread. Now, just like with future/promise, it *could* happen=
=20
that a single thread "owns" both the producing (promise) end of the channel=
=20
and the consuming (future) end of the channel... but it should also be=20
possible to have the producing end and consuming end located in different=
=20
threads, and this is in fact the *expected* case. Actually, I take back the=
=20
first part of that sentence =E2=80=94 if someone proposed a C++ channel who=
se two=20
ends *must* be in different threads or else deadlock, I wouldn't see=20
anything odd about that.

Now for the important thing that differentiates "channels" (in my vague=20
understanding) from "queues".  The point of a "channel" is that it never=20
(well, hardly ever) contains more than a single item =E2=80=94 because, as =
soon as=20
the producing thread hits the epilogue of its call to "chan << x", we=20
suspend that thread and go over to the consuming thread, which is almost=20
certainly blocked in the prologue of "chan >> x". We can then let the=20
consumer run until it returns to "chan >> x", at which point (the channel=
=20
now being empty) we suspend the consumer and switch back to the producer...=
=20
and so on.

I have very little experience with this stuff, but I know that Intel TBB's=
=20
"pipelines" and "flow graphs" are supposed to work this way =E2=80=94 alter=
nately=20
pushing and pulling data =E2=80=94 somehow. Maybe a channel primitive could=
 be=20
constructed out of a very pared-down TBB flow-graph?

my $.02,
=E2=80=93Arthur

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a157469b-d311-447a-917b-724ea3cb5123%40isocpp.or=
g.

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

<div dir=3D"ltr">On Thursday, October 13, 2016 at 1:39:26 PM UTC-7, Oliver =
Kowalke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote">2016-10-13 7:53 GMT+02:00 Aaron R Robinson=
 <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"B4gYqzLGAQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#=
39;;return true;">linux...@gmail.com</a>&gt;</span>:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><span><div>&gt;&gt; How is this compare to B=
oot Fiber channels and John Bandela&#39;s Channels (cppcon &#39;16)?</div><=
/span></div></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div>For the Boost Fiber Channels (BFC), the proposed implem=
entation is more inline with implementations of channels as they are known =
outside of C++.</div></div></blockquote><div><br></div><div>channels of boo=
st.fiber are not channels in the sense of GO channels - both types in fact =
are queues.<br></div><div>unbounded_queue: stores unlimited items<br></div>=
<div>bounded_queue: stores items only up to a maximum, any subsequent push =
operations will block until some items have been removed<br></div></div></d=
iv></div></blockquote><div><br></div><div>The code at https://bitbucket.org=
/linuxuser27/c-channel/src/eb4b53d2764c010b95c02714e095e149d8765929/channel=
s.h</div><div>also implements merely a bounded queue, AFAICT, and not what =
Go means by &quot;channels&quot;.</div><div><br></div><div>I don&#39;t know=
 whether Go-style channels are implementable in present-day C++; you might =
need to get more coroutine-awareness in the language first somehow (and in =
fact I would be pleasantly shocked if Gor&#39;s coroutines proposal was any=
where close to aware enough).</div><div><br></div><div>I would think that a=
 &quot;C++-ish&quot; channel should follow the same outline as std::future/=
std::promise =E2=80=94 it should be uni-directional as requested by Domen i=
n this thread. Now, just like with future/promise, it <i>could</i> happen t=
hat a single thread &quot;owns&quot; both the producing (promise) end of th=
e channel and the consuming (future) end of the channel... but it should al=
so be possible to have the producing end and consuming end located in diffe=
rent threads, and this is in fact the <i>expected</i> case. Actually, I tak=
e back the first part of that sentence =E2=80=94 if someone proposed a C++ =
channel whose two ends=C2=A0<i>must</i> be in different threads or else dea=
dlock, I wouldn&#39;t see anything odd about that.</div><div><br></div><div=
>Now for the important thing that differentiates &quot;channels&quot; (in m=
y vague understanding) from &quot;queues&quot;. =C2=A0The point of a &quot;=
channel&quot; is that it never (well, hardly ever) contains more than a sin=
gle item =E2=80=94 because, as soon as the producing thread hits the epilog=
ue of its call to &quot;chan &lt;&lt; x&quot;, we suspend that thread and g=
o over to the consuming thread, which is almost certainly blocked in the pr=
ologue of &quot;chan &gt;&gt; x&quot;. We can then let the consumer run unt=
il it returns to &quot;chan &gt;&gt; x&quot;, at which point (the channel n=
ow being empty) we suspend the consumer and switch back to the producer... =
and so on.</div><div><br></div><div>I have very little experience with this=
 stuff, but I know that Intel TBB&#39;s &quot;pipelines&quot; and &quot;flo=
w graphs&quot; are supposed to work this way =E2=80=94 alternately pushing =
and pulling data =E2=80=94 somehow. Maybe a channel primitive could be cons=
tructed out of a very pared-down TBB flow-graph?</div><div><br></div><div>m=
y $.02,</div><div>=E2=80=93Arthur</div></div>

<p></p>

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

------=_Part_781_566544772.1476414983137--

------=_Part_780_48511395.1476414983136--

.

--001a11402e9a7c7891053ecc61ee
Content-Type: text/plain; charset=UTF-8

2016-10-14 5:16 GMT+02:00 Arthur O'Dwyer <arthur.j.odwyer@gmail.com>:

>
> I don't know whether Go-style channels are implementable in present-day
> C++; you might need to get more coroutine-awareness in the language first
> somehow (and in fact I would be pleasantly shocked if Gor's coroutines
> proposal was anywhere close to aware enough).
>

it is possible with boost.fiber without blocking the entire thread (waiting
on a channel)

--
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/CA%2Bwfc1-PcZ6i6F1Ab%2BFj2RT7Rs3WJaiyC_yGKg1p%2B-oE%3DQY5CA%40mail.gmail.com.

--001a11402e9a7c7891053ecc61ee
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">2016=
-10-14 5:16 GMT+02:00 Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gmail.co=
m</a>&gt;</span>:<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"><br><d=
iv>I don&#39;t know whether Go-style channels are implementable in present-=
day C++; you might need to get more coroutine-awareness in the language fir=
st somehow (and in fact I would be pleasantly shocked if Gor&#39;s coroutin=
es proposal was anywhere close to aware enough).</div></div></blockquote><d=
iv><br></div><div>it is possible with boost.fiber without blocking the enti=
re thread (waiting on a channel)</div><br></div></div></div>

<p></p>

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

--001a11402e9a7c7891053ecc61ee--

.

--001a114da9eeae6824053f128bf0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Just now getting a chance to respond, so sorry for the late reply. This
seems quite close to what we've been doing with RaftLib (raftlib.io, also
CPPNow16). It constructs a compute graph of sequential communicating
actors. Each actor is connected via streams/channels. Each channel is
uni-directional and it is presumed that each actor executes on a separate
thread or fiber so that blocking on the channels can occur.

>If someone proposed a C++ channel whose two ends *must* be in different
threads or else deadlock, I wouldn't see anything odd about that.

Not sure if this needs to be a requirement or not. If each actor shares
state only through FIFO channels then it'd be fairly simple in the run-time
implementation to set call-backs for FIFO calls that would block so that
deadlock wouldn't occur. Essentially this would be implemented like fibers
(user-space threads, Sandia's Qthreads is a good place to look....). It is
likely a bad assumption to assume only a single item, given noise in most
systems (OS/hardware) the rates of each actor are often unmatched...so,
allowance for some buffering is usually necessary for performance, but not
needed for correctness.

Going to have to read over the rest of the proposal, will follow up in a
bit.

-Jonathan


On Thu, Oct 13, 2016 at 10:16 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com=
>
wrote:

> On Thursday, October 13, 2016 at 1:39:26 PM UTC-7, Oliver Kowalke wrote:
>>
>> 2016-10-13 7:53 GMT+02:00 Aaron R Robinson <linux...@gmail.com>:
>>
>>> >> How is this compare to Boot Fiber channels and John Bandela's
>>> Channels (cppcon '16)?
>>>
>>
>>
>>> For the Boost Fiber Channels (BFC), the proposed implementation is more
>>> inline with implementations of channels as they are known outside of C+=
+.
>>>
>>
>> channels of boost.fiber are not channels in the sense of GO channels -
>> both types in fact are queues.
>> unbounded_queue: stores unlimited items
>> bounded_queue: stores items only up to a maximum, any subsequent push
>> operations will block until some items have been removed
>>
>
> The code at https://bitbucket.org/linuxuser27/c-channel/src/
> eb4b53d2764c010b95c02714e095e149d8765929/channels.h
> also implements merely a bounded queue, AFAICT, and not what Go means by
> "channels".
>
> I don't know whether Go-style channels are implementable in present-day
> C++; you might need to get more coroutine-awareness in the language first
> somehow (and in fact I would be pleasantly shocked if Gor's coroutines
> proposal was anywhere close to aware enough).
>
> I would think that a "C++-ish" channel should follow the same outline as
> std::future/std::promise =E2=80=94 it should be uni-directional as reques=
ted by
> Domen in this thread. Now, just like with future/promise, it *could*
> happen that a single thread "owns" both the producing (promise) end of th=
e
> channel and the consuming (future) end of the channel... but it should al=
so
> be possible to have the producing end and consuming end located in
> different threads, and this is in fact the *expected* case. Actually, I
> take back the first part of that sentence =E2=80=94 if someone proposed a=
 C++
> channel whose two ends *must* be in different threads or else deadlock, I
> wouldn't see anything odd about that.
>
> Now for the important thing that differentiates "channels" (in my vague
> understanding) from "queues".  The point of a "channel" is that it never
> (well, hardly ever) contains more than a single item =E2=80=94 because, a=
s soon as
> the producing thread hits the epilogue of its call to "chan << x", we
> suspend that thread and go over to the consuming thread, which is almost
> certainly blocked in the prologue of "chan >> x". We can then let the
> consumer run until it returns to "chan >> x", at which point (the channel
> now being empty) we suspend the consumer and switch back to the producer.=
...
> and so on.
>
> I have very little experience with this stuff, but I know that Intel TBB'=
s
> "pipelines" and "flow graphs" are supposed to work this way =E2=80=94 alt=
ernately
> pushing and pulling data =E2=80=94 somehow. Maybe a channel primitive cou=
ld be
> constructed out of a very pared-down TBB flow-graph?
>
> my $.02,
> =E2=80=93Arthur
>
> --
> 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/a157469b-d311-447a-
> 917b-724ea3cb5123%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a157469b-d3=
11-447a-917b-724ea3cb5123%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/CAA1FrvmSb0zyXoJtQbU2fDwj%2BVHxeLmAMV6iAkZUheLZS=
cfwhg%40mail.gmail.com.

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

<div dir=3D"ltr"><span style=3D"font-size:12.8px">Just now getting a chance=
 to respond, so sorry for the late reply. This seems quite close to what we=
&#39;ve been doing with RaftLib (<a href=3D"http://raftlib.io">raftlib.io</=
a>, also CPPNow16). It constructs a compute graph of sequential communicati=
ng actors. Each actor is connected via streams/channels. Each channel is un=
i-directional and it is presumed that each actor executes on a separate thr=
ead or fiber so that blocking on the channels can occur.=C2=A0</span><div><=
span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-s=
ize:12.8px">&gt;If someone proposed a C++=C2=A0</span><span class=3D"gmail-=
il" style=3D"font-size:12.8px;background-color:rgb(255,255,255)">channel</s=
pan><span style=3D"font-size:12.8px">=C2=A0whose two ends=C2=A0</span><i st=
yle=3D"font-size:12.8px">must</i><span style=3D"font-size:12.8px">=C2=A0be =
in different threads or else deadlock, I wouldn&#39;t see anything odd abou=
t that.</span><br></div><div><br></div><div><span style=3D"font-size:12.8px=
">Not sure if this needs to be a requirement or not. If each actor shares s=
tate only through FIFO channels then it&#39;d be fairly simple in the run-t=
ime implementation to set call-backs for FIFO calls that would block so tha=
t deadlock wouldn&#39;t occur. Essentially this would be implemented like f=
ibers (user-space threads, Sandia&#39;s Qthreads is a good place to look...=
..). It is likely a bad assumption to assume only a single item, given noise=
 in most systems (OS/hardware) the rates of each actor are often unmatched.=
...so, allowance for some buffering is usually necessary for performance, bu=
t not needed for correctness.=C2=A0</span></div><div><span style=3D"font-si=
ze:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">Going to =
have to read over the rest of the proposal, will follow up in a bit.=C2=A0<=
/span></div><div><span style=3D"font-size:12.8px"><br></span></div><div><sp=
an style=3D"font-size:12.8px">-Jonathan</span></div><div><span style=3D"fon=
t-size:12.8px"><br></span></div></div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On Thu, Oct 13, 2016 at 10:16 PM, Arthur O&#39;Dwyer <=
span dir=3D"ltr">&lt;<a href=3D"mailto:arthur.j.odwyer@gmail.com" target=3D=
"_blank">arthur.j.odwyer@gmail.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">On Thursday, October 13, 2016 at 1:39:26 P=
M UTC-7, Oliver Kowalke wrote:<span class=3D""><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">2016-10-13 7:5=
3 GMT+02:00 Aaron R Robinson <span dir=3D"ltr">&lt;<a rel=3D"nofollow">linu=
x...@gmail.com</a>&gt;</span>:<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><div>&gt;&gt; How is this compare to Boot Fiber channels and=
 John Bandela&#39;s Channels (cppcon &#39;16)?</div></span></div></blockquo=
te><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Fo=
r the Boost Fiber Channels (BFC), the proposed implementation is more inlin=
e with implementations of channels as they are known outside of C++.</div><=
/div></blockquote><div><br></div><div>channels of boost.fiber are not chann=
els in the sense of GO channels - both types in fact are queues.<br></div><=
div>unbounded_queue: stores unlimited items<br></div><div>bounded_queue: st=
ores items only up to a maximum, any subsequent push operations will block =
until some items have been removed<br></div></div></div></div></blockquote>=
<div><br></div></span><div>The code at <a href=3D"https://bitbucket.org/lin=
uxuser27/c-channel/src/eb4b53d2764c010b95c02714e095e149d8765929/channels.h"=
 target=3D"_blank">https://bitbucket.org/<wbr>linuxuser27/c-channel/src/<wb=
r>eb4b53d2764c010b95c02714e095e1<wbr>49d8765929/channels.h</a></div><div>al=
so implements merely a bounded queue, AFAICT, and not what Go means by &quo=
t;channels&quot;.</div><div><br></div><div>I don&#39;t know whether Go-styl=
e channels are implementable in present-day C++; you might need to get more=
 coroutine-awareness in the language first somehow (and in fact I would be =
pleasantly shocked if Gor&#39;s coroutines proposal was anywhere close to a=
ware enough).</div><div><br></div><div>I would think that a &quot;C++-ish&q=
uot; channel should follow the same outline as std::future/std::promise =E2=
=80=94 it should be uni-directional as requested by Domen in this thread. N=
ow, just like with future/promise, it <i>could</i> happen that a single thr=
ead &quot;owns&quot; both the producing (promise) end of the channel and th=
e consuming (future) end of the channel... but it should also be possible t=
o have the producing end and consuming end located in different threads, an=
d this is in fact the <i>expected</i> case. Actually, I take back the first=
 part of that sentence =E2=80=94 if someone proposed a C++ channel whose tw=
o ends=C2=A0<i>must</i> be in different threads or else deadlock, I wouldn&=
#39;t see anything odd about that.</div><div><br></div><div>Now for the imp=
ortant thing that differentiates &quot;channels&quot; (in my vague understa=
nding) from &quot;queues&quot;.=C2=A0 The point of a &quot;channel&quot; is=
 that it never (well, hardly ever) contains more than a single item =E2=80=
=94 because, as soon as the producing thread hits the epilogue of its call =
to &quot;chan &lt;&lt; x&quot;, we suspend that thread and go over to the c=
onsuming thread, which is almost certainly blocked in the prologue of &quot=
;chan &gt;&gt; x&quot;. We can then let the consumer run until it returns t=
o &quot;chan &gt;&gt; x&quot;, at which point (the channel now being empty)=
 we suspend the consumer and switch back to the producer... and so on.</div=
><div><br></div><div>I have very little experience with this stuff, but I k=
now that Intel TBB&#39;s &quot;pipelines&quot; and &quot;flow graphs&quot; =
are supposed to work this way =E2=80=94 alternately pushing and pulling dat=
a =E2=80=94 somehow. Maybe a channel primitive could be constructed out of =
a very pared-down TBB flow-graph?</div><div><br></div><div>my $.02,</div><d=
iv>=E2=80=93Arthur</div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a157469b-d311-447a-917b-724ea3cb5123%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/a157=
469b-d311-447a-<wbr>917b-724ea3cb5123%40isocpp.org</a><wbr>.<br>
</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA1FrvmSb0zyXoJtQbU2fDwj%2BVHxeLmAMV=
6iAkZUheLZScfwhg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA1FrvmSb0zyXo=
JtQbU2fDwj%2BVHxeLmAMV6iAkZUheLZScfwhg%40mail.gmail.com</a>.<br />

--001a114da9eeae6824053f128bf0--

.

------=_Part_520_666276399.1476894446357
Content-Type: multipart/alternative;
 boundary="----=_Part_521_1303844295.1476894446357"

------=_Part_521_1303844295.1476894446357
Content-Type: text/plain; charset=UTF-8

On Wednesday, October 12, 2016 at 10:53:40 PM UTC-7, Aaron R Robinson wrote:
>
> >> - Channel is bidirectional only. I would expect an additional producer
> channel that would have a make_consumer member function enforcing single
> producer multiple consumers pattern (not certain if multiple producers
> single consumer would also be useful).
>
> I don't quite understand this statement. I can say that channels do not
> and should not have any concept of directionality - they are always
> bidirectional. A thread given a channel can either read from it or write to
> it and that is by-design. I can definitely see the potential benefit from a
> wrapper class that enforces a single direction, but that would be an
> extension to a fully bidirectional channel.
>

But _why_ is it by design?

Bidirectionality is trivially implemented (efficiently) using two
unidirectional channels, but a unidirectional channel built over a
bidirectional channel is nothing more than a limitation imposed with no
memory usage improvements. It seems to me that unidirectional channels are
the simplest and least error-prone building block.

Code I work on at least is rather littered with unidirectional
producer-consumer queues - very similar in concept to a unidirectional
channel - and adding additional memory or complexity to allow bidirectional
communication that I'd then have to write additional wrapper code to
disable is a pure _loss_ in usability and efficiency.

It's worth noting perhaps that Rust and Haskell both use unidirectional
channels by default and that Go has first-class support for unidirectional
channels.

>>> - Channel is using a single communication type so for bidirectional
channel a custom structure would have to be of a single type even if
request and response differ unless variant or any would be used. It would
be a nice to have feature to support this internally but since this
functionality can be added as a derived class this is not as important.

> The appropriate approach here would be to either have a channel the
producer would read from and one it would write from since all the channel
is doing is synchronizing the transmission of data/state.

That's a problem with bidirectional channels only. Unidirectional channels
would not allow a producer to read from its end of the channel, hence
guaranteeing it can never pop its own value.

This again pointing out that unidirectional channels are safer building
blocks. They're far harder to use incorrectly, especially if you leverage
the type system appropriately in your interface e.g. creating a
unidirectional channel should provide two separate objects - a producer end
and a consumer end - while a bidirectional channel is just two objects that
each contain a producer and a consumer end (from two separate channels).

This brings up the comparison again to futures/promises - separate the
producer from the consumer.

--
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/97f6bdfb-5016-4a39-aa1a-1ca7f939eb4e%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, October 12, 2016 at 10:53:40 PM UTC-7, Aaron=
 R Robinson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div>&gt;&gt; - Channel is bidirectional only. I would expect an addit=
ional producer channel that would have a make_consumer member function enfo=
rcing single producer multiple consumers pattern (not certain if multiple p=
roducers single consumer would also be useful).<br></div><div><br></div><di=
v>I don&#39;t quite understand this statement. I can say that channels do n=
ot and should not have any concept of directionality - they are always bidi=
rectional. A thread given a channel can either read from it or write to it =
and that is by-design. I can definitely see the potential benefit from a wr=
apper class that enforces a single direction, but that would be an extensio=
n to a fully bidirectional channel.</div></div></blockquote><div><br></div>=
<div>But _why_ is it by design?</div><div><br></div><div>Bidirectionality i=
s trivially implemented (efficiently) using two unidirectional channels, bu=
t a unidirectional channel built over a bidirectional channel is nothing mo=
re than a limitation imposed with no memory usage improvements. It seems to=
 me that unidirectional channels are the simplest and least error-prone bui=
lding block.</div><div><br></div><div>Code I work on at least is rather lit=
tered with unidirectional producer-consumer queues - very similar in concep=
t to a unidirectional channel - and adding additional memory or complexity =
to allow bidirectional communication that I&#39;d then have to write additi=
onal wrapper code to disable is a pure _loss_ in usability and efficiency.<=
/div><div><br></div><div>It&#39;s worth noting perhaps that Rust and Haskel=
l both use unidirectional channels by default and that Go has first-class s=
upport for unidirectional channels.</div><div><br></div><div><div class=3D"=
IVILX2C-Db-b"><div>&gt;&gt;&gt; - Channel is using a single communication t=
ype so for bidirectional channel a custom structure would have to be of a s=
ingle type even if request and response differ unless variant or any would =
be used. It would be a nice to have feature to support this internally but =
since this functionality can be added as a derived class this is not as imp=
ortant.</div><div><br></div></div><div>&gt; The appropriate approach here w=
ould be to either have a channel the producer would read from and one it wo=
uld write from since all the channel is doing is synchronizing the transmis=
sion of data/state.=C2=A0</div></div><div><br></div><div>That&#39;s a probl=
em with bidirectional channels only. Unidirectional channels would not allo=
w a producer to read from its end of the channel, hence guaranteeing it can=
 never pop its own value.<br></div><div><br></div><div>This again pointing =
out that unidirectional channels are safer building blocks. They&#39;re far=
 harder to use incorrectly, especially if you leverage the type system appr=
opriately in your interface e.g. creating a unidirectional channel should p=
rovide two separate objects - a producer end and a consumer end - while a b=
idirectional channel is just two objects that each contain a producer and a=
 consumer end (from two separate channels).</div><div><br></div><div>This b=
rings up the comparison again to futures/promises - separate the producer f=
rom the consumer.</div><div><br></div></div>

<p></p>

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

------=_Part_521_1303844295.1476894446357--

------=_Part_520_666276399.1476894446357--

.

On 10/19/2016 05:27 PM, Sean Middleditch wrote:
> On Wednesday, October 12, 2016 at 10:53:40 PM UTC-7, Aaron R Robinson wrote:
>
>     >> - Channel is bidirectional only. I would expect an additional
>     producer channel that would have a make_consumer member function
>     enforcing single producer multiple consumers pattern (not certain if
>     multiple producers single consumer would also be useful).
>
>     I don't quite understand this statement. I can say that channels do
>     not and should not have any concept of directionality - they are
>     always bidirectional. A thread given a channel can either read from
>     it or write to it and that is by-design. I can definitely see the
>     potential benefit from a wrapper class that enforces a single
>     direction, but that would be an extension to a fully bidirectional
>     channel.
>
>
> But _why_ is it by design?
>
> Bidirectionality is trivially implemented (efficiently) using two
> unidirectional channels, but a unidirectional channel built over a
> bidirectional channel is nothing more than a limitation imposed with no
> memory usage improvements. It seems to me that unidirectional channels
> are the simplest and least error-prone building block.

I think also it is better to start from unidirectional channels because
it is what the hardware can do best at the wire level.

In C++ we just pay for what we need. Why paying for a bidirectional
channel when only 1 way is required?
It is important for SG14.
In OpenCL C++ 2.2 the pipe<> objects are unidirectional too.
It really makes sense when using C++ outside of the plain old CPU +
memory world and use it to program FPGA or make ASIC.
--
Ronan KERYELL, Xilinx Research Labs / Ireland.

--
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/d24d450e-da31-7b66-ccc0-23c8308c137f%40xilinx.com.

.

--e89a8fb1fffe812cf0053f652cf9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 19, 2016 at 9:27 AM, Sean Middleditch <
sean.middleditch@gmail.com> wrote:

> On Wednesday, October 12, 2016 at 10:53:40 PM UTC-7, Aaron R Robinson
> wrote:
>>
>> >> - Channel is bidirectional only. I would expect an additional produce=
r
>> channel that would have a make_consumer member function enforcing single
>> producer multiple consumers pattern (not certain if multiple producers
>> single consumer would also be useful).
>>
>> I don't quite understand this statement. I can say that channels do not
>> and should not have any concept of directionality - they are always
>> bidirectional. A thread given a channel can either read from it or write=
 to
>> it and that is by-design. I can definitely see the potential benefit fro=
m a
>> wrapper class that enforces a single direction, but that would be an
>> extension to a fully bidirectional channel.
>>
>
> But _why_ is it by design?
>

Please remember that the concept Aaron is describing is not a "channel" as
implemented by Golang <https://tour.golang.org/concurrency/2>, etc.; it's a
"concurrent bounded queue", as implemented by TBB
<https://software.intel.com/en-us/node/506200>, Lawrence Crowl's P0260
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0260r0.html>,
etc.  Let me explain what I'm thinking...

*Any* kind of queue is fundamentally "bidirectional", in that the queue
object itself has a push method and a pop method; it's unthinkable to have
a "queue" without push and pop methods.  So we don't usually use the word
"bidirectional" for a queue; we just say that it's a queue, and everybody
knows what we mean.  The special thing about a concurrent queue is that
different threads can call push and/or pop "simultaneously" without
introducing data races.  (The meaning of "and/or" is explored more below.)

Notice that if your data structure exposes "fullness" to the user (by
throwing, returning false, or undefined behavior) then what you have is not
exactly a "queue" anymore but more like a vector or ringbuffer.  But once
you add concurrency, you have another option: instead of exposing fullness,
push() on a full queue can simply block until the queue becomes non-full
through the action of another thread.  If your data structure has a
potentially blocking push(), we can call it "bounded"; if your push()
cannot fail, we call your data structure "unbounded".

When we say "different threads can call push and/or pop without data
races": if this is literally true, we have a multi-producer multi-consumer
queue (MPMC).  But sometimes we can make the implementation more efficient
if we assume there will never be multiple people calling push()
simultaneously (but still might be multiple people calling pop()): that's
single-producer multi-consumer (SPMC). Or alternatively MPSC, or the
simplest and thus hopefully most efficient case, SPSC.

Any language (but especially C++) has basically two ways of dealing with
concurrency. Either you design your interface so that different threads
never need to manipulate the same object simultaneously (see:
promise/future) or else you design your interface so that operations that
might need to happen simultaneously on the same object are guaranteed
thread-safe (see: atomic<int>).

Concurrent queues in C++ (Boost.Fiber, TBB, P0260) generally take the
latter approach.  If you applied the former approach to a concurrent queue,
you'd split its logical interface into a "push/producer end" and a
"pop/consumer end". Then it's no longer required for the producer thread
and the consumer thread to manipulate the same queue object; the producer
thread simply manipulates the "producer end", and the consumer thread
simply manipulates the "consumer end", and any synchronization between the
two ends becomes a detail of the hidden implementation.  ...At least, this
is true if you're designing a SPSC queue. If you want a MPSC queue, then
you'd have to provide a way for each producer thread to get its own
"producer end" object; and so on.

If you have a SPSC concurrent queue whose "ends" have been split like this,
you could call it a "channel"; although I personally would reserve that
term for concurrent bounded queues with capacity 1 whose ends are aware of
each other's owning coroutines so that producing into a channel implicitly
context-switches to the coroutine in charge of consumption. In the
paragraphs that follow, I will call a "split" queue "unidirectional" and a
TBB-style queue "bidirectional".

What Rust calls a "channel"
<https://doc.rust-lang.org/std/sync/mpsc/fn.channel.html> is a
unidirectional SPSC concurrent unbounded queue, in that reads and writes
are guaranteed not to block =E2=80=94 but the producer and consumer "ends" =
are
logically separated.
Rust also supports "sync channels"
<https://doc.rust-lang.org/std/sync/mpsc/fn.sync_channel.html>, a.k.a.
unidirectional SPSC concurrent bounded queues of any specified capacity.

What Golang calls a "channel" <https://tour.golang.org/concurrency/2> is a
unidirectional SPSC concurrent bounded queue with capacity 1, in that reads
and writes are guaranteed to block =E2=80=94 and again the producer and con=
sumer
"ends" are logically separated.  (I intuitively believe that these channels
implement the coroutine switching I described above, but I admit I don't
know for sure.)
Golang also supports "buffered channels"
<https://tour.golang.org/concurrency/3>, a.k.a. unidirectional SPSC
concurrent bounded queues of any specified capacity.

Boost.Fiber supports "unbounded_channel"
<http://www.boost.org/doc/libs/1_62_0/libs/fiber/doc/html/fiber/synchroniza=
tion/channels.html>,
a.k.a. bidirectional MPMC(?) concurrent unbounded queues.
Boost.Fiber also supports "bounded_channel"
<http://www.boost.org/doc/libs/1_62_0/libs/fiber/doc/html/fiber/synchroniza=
tion/channels.html>,
a.k.a. bidirectional MPMC(?) concurrent bounded queues of any specified
capacity; with the additional feature of a "low water mark" such that once
the queue has become full, every subsequent push() will block until the
number of items in the queue has dropped below the low water mark. That is,
push-blocking-ness can be specified to be a bit "sticky" in this
implementation.

Haskell's Chan
<https://hackage.haskell.org/package/base-4.9.0.0/docs/Control-Concurrent-C=
han.html>
and
TChan
<https://hackage.haskell.org/package/stm-2.4.4.1/docs/Control-Concurrent-ST=
M-TChan.html>
types, which they colloquially call "broadcast channels", seem almost like
pubsubs, in that you can "duplicate" a Chan to subscribe to all future
updates even if those future updates are also being consumed by someone
else. This seems to me like just as egregious a misuse of the term
"channel" as Boost.Fiber's. (But I don't know Haskell conventions so I
might be misunderstanding what they're doing.)


Sean wrote:

> Bidirectionality is trivially implemented (efficiently) using two
> unidirectional channels, but a unidirectional channel built over a
> bidirectional channel is nothing more than a limitation imposed with no
> memory usage improvements. It seems to me that unidirectional channels ar=
e
> the simplest and least error-prone building block.
>

Notice that you cannot build a bidirectional MPMC concurrent queue out of
unidirectional SPSC concurrent queues.


> [...] This again pointing out that unidirectional channels are safer
> building blocks. They're far harder to use incorrectly, especially if you
> leverage the type system appropriately in your interface e.g. creating a
> unidirectional channel should provide two separate objects - a producer e=
nd
> and a consumer end - while a bidirectional channel is just two objects th=
at
> each contain a producer and a consumer end (from two separate channels).
>

I agree that unidirectional "ends", promise/future-style are more
modern-C++ish than thread-safe concurrent_queue-style building blocks.
However, there might be room for both, ideally within some nice rational
framework.

=E2=80=93Arthur

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

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

<div dir=3D"ltr">On Wed, Oct 19, 2016 at 9:27 AM, Sean Middleditch <span di=
r=3D"ltr">&lt;<a href=3D"mailto:sean.middleditch@gmail.com" target=3D"_blan=
k">sean.middleditch@gmail.com</a>&gt;</span> wrote:<br><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-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">On We=
dnesday, October 12, 2016 at 10:53:40 PM UTC-7, Aaron R Robinson wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div>&gt;&gt; - Channel is bidirectional only=
.. I would expect an additional producer channel that would have a make_cons=
umer member function enforcing single producer multiple consumers pattern (=
not certain if multiple producers single consumer would also be useful).<br=
></div><div><br></div><div>I don&#39;t quite understand this statement. I c=
an say that channels do not and should not have any concept of directionali=
ty - they are always bidirectional. A thread given a channel can either rea=
d from it or write to it and that is by-design. I can definitely see the po=
tential benefit from a wrapper class that enforces a single direction, but =
that would be an extension to a fully bidirectional channel.</div></div></b=
lockquote><div><br></div><div>But _why_ is it by design?</div></div></block=
quote><div><br></div><div>Please remember that the concept Aaron is describ=
ing is not a &quot;channel&quot; as implemented by <a href=3D"https://tour.=
golang.org/concurrency/2">Golang</a>, etc.; it&#39;s a &quot;concurrent bou=
nded queue&quot;, as implemented by <a href=3D"https://software.intel.com/e=
n-us/node/506200">TBB</a>,=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc2=
2/wg21/docs/papers/2016/p0260r0.html">Lawrence Crowl&#39;s=C2=A0P0260</a>, =
etc.=C2=A0 Let me explain what I&#39;m thinking...</div><div><br></div><div=
><i>Any</i> kind of queue is fundamentally &quot;bidirectional&quot;, in th=
at the queue object itself has a push method and a pop method; it&#39;s unt=
hinkable to have a &quot;queue&quot; without push and pop methods.=C2=A0 So=
 we don&#39;t usually use the word &quot;bidirectional&quot; for a queue; w=
e just say that it&#39;s a queue, and everybody knows what we mean.=C2=A0 T=
he special thing about a concurrent queue is that different threads can cal=
l push and/or pop &quot;simultaneously&quot; without introducing data races=
.. =C2=A0(The meaning of &quot;and/or&quot; is explored more below.)</div><d=
iv><br></div><div>Notice that if your data structure exposes &quot;fullness=
&quot; to the user (by throwing, returning false, or undefined behavior) th=
en what you have is not exactly a &quot;queue&quot; anymore but more like a=
 vector or ringbuffer.=C2=A0 But once you add concurrency, you have another=
 option: instead of exposing fullness, push() on a full queue can simply bl=
ock until the queue becomes non-full through the action of another thread.=
=C2=A0 If your data structure has a potentially blocking push(), we can cal=
l it &quot;bounded&quot;; if your push() cannot fail, we call your data str=
ucture &quot;unbounded&quot;.<br></div><div><br></div><div>When we say &quo=
t;different threads can call push and/or pop without data races&quot;: if t=
his is literally true, we have a multi-producer multi-consumer queue (MPMC)=
..=C2=A0 But sometimes we can make the implementation more efficient if we a=
ssume there will never be multiple people calling push() simultaneously (bu=
t still might be multiple people calling pop()): that&#39;s single-producer=
 multi-consumer (SPMC). Or alternatively MPSC, or the simplest and thus hop=
efully most efficient case, SPSC.</div><div><br></div><div>Any language (bu=
t especially C++) has basically two ways of dealing with concurrency. Eithe=
r you design your interface so that different threads never need to manipul=
ate the same object simultaneously (see: promise/future) or else you design=
 your interface so that operations that might need to happen simultaneously=
 on the same object are guaranteed thread-safe (see: atomic&lt;int&gt;).</d=
iv><div><br></div><div>Concurrent queues in C++ (Boost.Fiber, TBB, P0260) g=
enerally take the latter approach.=C2=A0 If you applied the former approach=
 to a concurrent queue, you&#39;d split its logical interface into a &quot;=
push/producer end&quot; and a &quot;pop/consumer end&quot;. Then it&#39;s n=
o longer required for the producer thread and the consumer thread to manipu=
late the same queue object; the producer thread simply manipulates the &quo=
t;producer end&quot;, and the consumer thread simply manipulates the &quot;=
consumer end&quot;, and any synchronization between the two ends becomes a =
detail of the hidden implementation. =C2=A0...At least, this is true if you=
&#39;re designing a SPSC queue. If you want a MPSC queue, then you&#39;d ha=
ve to provide a way for each producer thread to get its own &quot;producer =
end&quot; object; and so on.</div><div><br></div><div>If you have a SPSC co=
ncurrent queue whose &quot;ends&quot; have been split like this, you could =
call it a &quot;channel&quot;; although I personally would reserve that ter=
m for concurrent bounded queues with capacity 1 whose ends are aware of eac=
h other&#39;s owning coroutines so that producing into a channel implicitly=
 context-switches to the coroutine in charge of consumption. In the paragra=
phs that follow, I will call a &quot;split&quot; queue &quot;unidirectional=
&quot; and a TBB-style queue &quot;bidirectional&quot;.</div><div><br></div=
><div><a href=3D"https://doc.rust-lang.org/std/sync/mpsc/fn.channel.html">W=
hat Rust calls a &quot;channel&quot;</a> is a unidirectional SPSC concurren=
t unbounded=C2=A0queue, in that reads and writes are guaranteed not to bloc=
k =E2=80=94 but the producer and consumer &quot;ends&quot; are logically se=
parated.</div><div><a href=3D"https://doc.rust-lang.org/std/sync/mpsc/fn.sy=
nc_channel.html">Rust also supports &quot;sync channels&quot;</a>, a.k.a. u=
nidirectional SPSC concurrent bounded queues of any specified capacity.</di=
v><div><br></div><div><a href=3D"https://tour.golang.org/concurrency/2">Wha=
t Golang calls a &quot;channel&quot;</a> is a unidirectional SPSC concurren=
t bounded queue with capacity 1, in that reads and writes are guaranteed to=
 block =E2=80=94 and again the producer and consumer &quot;ends&quot; are l=
ogically separated. =C2=A0(I intuitively believe that these channels implem=
ent the coroutine switching I described above, but I admit I don&#39;t know=
 for sure.)</div><div><a href=3D"https://tour.golang.org/concurrency/3">Gol=
ang also supports &quot;buffered channels&quot;</a>, a.k.a. unidirectional =
SPSC concurrent bounded queues of any specified capacity.</div><div><br></d=
iv><div><a href=3D"http://www.boost.org/doc/libs/1_62_0/libs/fiber/doc/html=
/fiber/synchronization/channels.html">Boost.Fiber supports &quot;unbounded_=
channel&quot;</a>, a.k.a. bidirectional MPMC(?) concurrent unbounded queues=
..</div><div><a href=3D"http://www.boost.org/doc/libs/1_62_0/libs/fiber/doc/=
html/fiber/synchronization/channels.html">Boost.Fiber also supports &quot;b=
ounded_channel&quot;</a>, a.k.a. bidirectional MPMC(?) concurrent bounded q=
ueues of any specified capacity; with the additional feature of a &quot;low=
 water mark&quot; such that once the queue has become full, every subsequen=
t push() will block until the number of items in the queue has dropped belo=
w the low water mark. That is, push-blocking-ness can be specified to be a =
bit &quot;sticky&quot; in this implementation.</div><div><br></div><div><a =
href=3D"https://hackage.haskell.org/package/base-4.9.0.0/docs/Control-Concu=
rrent-Chan.html">Haskell&#39;s Chan</a>=C2=A0and <a href=3D"https://hackage=
..haskell.org/package/stm-2.4.4.1/docs/Control-Concurrent-STM-TChan.html">TC=
han</a> types, which they colloquially call &quot;broadcast channels&quot;,=
 seem almost like pubsubs, in that you can &quot;duplicate&quot; a Chan to =
subscribe to all future updates even if those future updates are also being=
 consumed by someone else. This seems to me like just as egregious a misuse=
 of the term &quot;channel&quot; as Boost.Fiber&#39;s. (But I don&#39;t kno=
w Haskell conventions so I might be misunderstanding what they&#39;re doing=
..)</div><div><br></div><div><br></div><div>Sean wrote:</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;=
border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex=
"><div dir=3D"ltr"><div>Bidirectionality is trivially implemented (efficien=
tly) using two unidirectional channels, but a unidirectional channel built =
over a bidirectional channel is nothing more than a limitation imposed with=
 no memory usage improvements. It seems to me that unidirectional channels =
are the simplest and least error-prone building block.<br></div></div></blo=
ckquote><div><br></div><div>Notice that you cannot build a bidirectional MP=
MC concurrent queue out of unidirectional SPSC concurrent queues.</div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>[...] This a=
gain pointing out that unidirectional channels are safer building blocks. T=
hey&#39;re far harder to use incorrectly, especially if you leverage the ty=
pe system appropriately in your interface e.g. creating a unidirectional ch=
annel should provide two separate objects - a producer end and a consumer e=
nd - while a bidirectional channel is just two objects that each contain a =
producer and a consumer end (from two separate channels).</div></div></bloc=
kquote><div><br></div><div>I agree that unidirectional &quot;ends&quot;, pr=
omise/future-style are more modern-C++ish than thread-safe concurrent_queue=
-style building blocks. However, there might be room for both, ideally with=
in some nice rational framework.</div><div><br></div><div>=E2=80=93Arthur</=
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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0JN3e_dp6mgh9GVCcVq%2BzhBGdUTX9=
KeHfw96SUwV8zTrA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0JN3e_dp6=
mgh9GVCcVq%2BzhBGdUTX9KeHfw96SUwV8zTrA%40mail.gmail.com</a>.<br />

--e89a8fb1fffe812cf0053f652cf9--

.

--001a11402e9a40b54b053f715655
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2016-10-21 21:37 GMT+02:00 Arthur O'Dwyer <arthur.j.odwyer@gmail.com>:

> What Golang calls a "channel" <https://tour.golang.org/concurrency/2> is
> a unidirectional SPSC concurrent bounded queue with capacity 1, in that
> reads and writes are guaranteed to block =E2=80=94 and again the producer=
 and
> consumer "ends" are logically separated.  (I intuitively believe that the=
se
> channels implement the coroutine switching I described above, but I admit=
 I
> don't know for sure.)
> Golang also supports "buffered channels"
> <https://tour.golang.org/concurrency/3>, a.k.a. unidirectional SPSC
> concurrent bounded queues of any specified capacity.
>

I'm wondering because my understanding was that Go channels are per default
unbuffered with capacity 0. A push operation is blocked (goroutine gets
suspended) till another goroutine consumes the pushed data; a pop operation
will block (suspending the goroutine) if no producer is waiting or
immediately return otherwise.
Buffered Go channels are created by specifying a capacity (at least 1) at
creation.
Go channels are per default bidirectional (push and pop operations can be
invoked on the channel by the same goroutine) but can created as
unidirectional: 'c chan<- int' =3D=3D only push operations on channel c
allowed, 'c <-chan int' =3D=3D only pop operations allowed.

What I'm missing?


> a misuse of the term "channel" as Boost.Fiber's.
>

in which sense?

--=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/CA%2Bwfc19Sz4OQ4G08YU3fyiRrA2NsvgBGgfrLda_hfVjMo=
S8vag%40mail.gmail.com.

--001a11402e9a40b54b053f715655
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">2016=
-10-21 21:37 GMT+02:00 Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a href=3D"=
mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gmail.c=
om</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div></=
div><div><a href=3D"https://tour.golang.org/concurrency/2" target=3D"_blank=
">What Golang calls a &quot;channel&quot;</a> is a unidirectional SPSC conc=
urrent bounded queue with capacity 1, in that reads and writes are guarante=
ed to block =E2=80=94 and again the producer and consumer &quot;ends&quot; =
are logically separated. =C2=A0(I intuitively believe that these channels i=
mplement the coroutine switching I described above, but I admit I don&#39;t=
 know for sure.)</div><div><a href=3D"https://tour.golang.org/concurrency/3=
" target=3D"_blank">Golang also supports &quot;buffered channels&quot;</a>,=
 a.k.a. unidirectional SPSC concurrent bounded queues of any specified capa=
city.</div></div></div></div></blockquote><div><br>I&#39;m wondering becaus=
e my understanding was that Go channels are per default unbuffered with cap=
acity 0. A push operation is blocked (goroutine gets suspended) till anothe=
r goroutine consumes the pushed data; a pop operation will block (suspendin=
g the goroutine) if no producer is waiting or immediately return otherwise.=
<br>Buffered Go channels are created by specifying a capacity (at least 1) =
at creation.<br>Go channels are per default bidirectional (push and pop ope=
rations can be invoked on the channel by the same goroutine) but can create=
d as unidirectional: &#39;c chan&lt;- int&#39; =3D=3D only push operations =
on channel c allowed, &#39;c &lt;-chan int&#39; =3D=3D only pop operations =
allowed.<br><br>What I&#39;m missing?<br>=C2=A0</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 class=3D"gmail_extra"><di=
v class=3D"gmail_quote">a misuse of the term &quot;channel&quot; as Boost.F=
iber&#39;s.<br></div></div></div></blockquote></div><br></div><div class=3D=
"gmail_extra">in which sense?<br></div></div>

<p></p>

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

--001a11402e9a40b54b053f715655--

.

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

On Sat, Oct 22, 2016 at 3:07 AM, Oliver Kowalke <oliver.kowalke@gmail.com>
wrote:

> 2016-10-21 21:37 GMT+02:00 Arthur O'Dwyer <arthur.j.odwyer@gmail.com>:
>
>> What Golang calls a "channel" <https://tour.golang.org/concurrency/2> is
>> a unidirectional SPSC concurrent bounded queue with capacity 1, in that
>> reads and writes are guaranteed to block =E2=80=94 and again the produce=
r and
>> consumer "ends" are logically separated.  (I intuitively believe that th=
ese
>> channels implement the coroutine switching I described above, but I admi=
t I
>> don't know for sure.)
>> Golang also supports "buffered channels"
>> <https://tour.golang.org/concurrency/3>, a.k.a. unidirectional SPSC
>> concurrent bounded queues of any specified capacity.
>>
>
> I'm wondering because my understanding was that Go channels are per
> default unbuffered with capacity 0.
>

You're correct that Golang's own documentation describes its channels as
"capacity 0"; but in the terminology I was using, that would mean you could
never put anything into the channel because it would always be full!
Whether you think of it as "0 capacity, 1 element allowed in-flight as a
special case" or "1 capacity, 0 elements allowed in-flight as a special
case" is basically just an implementation detail of the theory AFAIC. :)
(But in terms of specifying the runtime semantics and in terms of
implementation, it does probably make things simpler to treat that
"in-flight" element specially. I don't know for sure.)

A push operation is blocked (goroutine gets suspended) till another
> goroutine consumes the pushed data; a pop operation will block (suspendin=
g
> the goroutine) if no producer is waiting or immediately return otherwise.
> Buffered Go channels are created by specifying a capacity (at least 1) at
> creation.
>

Agreed.


> Go channels are per default bidirectional (push and pop operations can be
> invoked on the channel by the same goroutine) but can created as
> unidirectional: 'c chan<- int' =3D=3D only push operations on channel c
> allowed, 'c <-chan int' =3D=3D only pop operations allowed.
>

I wasn't aware of this; thanks!
Notice that invoking push or pop on an "unbuffered" channel confined to a
single thread will always deadlock; but Go does allow you to write code
like "ch <- 1; fmt.Println(<-ch)" within a single thread as long as "ch" is
buffered.

I now think I was also wrong about their SPSC-ness. Not only can you have
multiple "handles" to a single conceptual channel, but you can actually
access a single handle simultaneously via pointers from different threads =
=E2=80=94
which I think is not true of Rust and certainly shouldn't be true of C++. (=
The
official docs indicate <https://golang.org/ref/mem#tmp_7> that you can
reliably access a single "chan" object from multiple goroutines
simultaneously, even though the same is not true of "map"
<https://golang.org/doc/faq#atomic_maps>.)
So, revised:

What Golang calls a "channel" <https://tour.golang.org/concurrency/2>
is a *bidirectional
MPMC* concurrent bounded queue with capacity 1, in that reads and writes
are guaranteed to block =E2=80=94 and again the producer and consumer "ends=
" are
logically separated.  (I intuitively believe that these channels implement
the coroutine switching I described above, but I admit I don't know for
sure.)
Golang also supports "buffered channels"
<https://tour.golang.org/concurrency/3>, a.k.a. *bidirectional MPMC*
concurrent bounded queues of any specified capacity.


What I'm missing?
>
>
>> a misuse of the term "channel" as Boost.Fiber's.
>>
>
> in which sense?
>

I don't believe that the term "channel" should be used to refer to a
"concurrent queue" object.  The point of a channel, in my mind, is that it
is SPSC and preferably capacity-1 (or capacity-0 in Go's terms); this is
what lets you make it fast.  If you add features until you've got a
bidirectional MPMC concurrent bounded queue =E2=80=94 or in Boost.Fiber's c=
ase a
bidirectional MPMC concurrent *unbounded* queue =E2=80=94 then not only do =
you lose
a lot of performance, but you're just duplicating work that's already been
done by queue implementations such as TBB
<https://software.intel.com/en-us/node/506200>.

At the very least, if you're designing a data structure whose public API is
exactly the public API of std::queue, please call it some variation on
"queue" or "concurrent_queue" so that people can find and understand it!
If you call it "channel", I for one am going to assume that it's got
semantics that are somehow different from a queue's.

=E2=80=93Arthur

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

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

<div dir=3D"ltr">On Sat, Oct 22, 2016 at 3:07 AM, Oliver Kowalke <span dir=
=3D"ltr">&lt;<a href=3D"mailto:oliver.kowalke@gmail.com" target=3D"_blank">=
oliver.kowalke@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"gmail-">2016-10-=
21 21:37 GMT+02:00 Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a href=3D"mail=
to:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gmail.com</=
a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:=
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><div></div><div><a href=3D"https://tour.gola=
ng.org/concurrency/2" target=3D"_blank">What Golang calls a &quot;channel&q=
uot;</a> is a unidirectional SPSC concurrent bounded queue with capacity 1,=
 in that reads and writes are guaranteed to block =E2=80=94 and again the p=
roducer and consumer &quot;ends&quot; are logically separated. =C2=A0(I int=
uitively believe that these channels implement the coroutine switching I de=
scribed above, but I admit I don&#39;t know for sure.)</div><div><a href=3D=
"https://tour.golang.org/concurrency/3" target=3D"_blank">Golang also suppo=
rts &quot;buffered channels&quot;</a>, a.k.a. unidirectional SPSC concurren=
t bounded queues of any specified capacity.</div></div></div></div></blockq=
uote></span><div><br>I&#39;m wondering because my understanding was that Go=
 channels are per default unbuffered with capacity 0.</div></div></div></di=
v></blockquote><div><br></div><div>You&#39;re correct that Golang&#39;s own=
 documentation describes its channels as &quot;capacity 0&quot;; but in the=
 terminology I was using, that would mean you could never put anything into=
 the channel because it would always be full! Whether you think of it as &q=
uot;0 capacity, 1 element allowed in-flight as a special case&quot; or &quo=
t;1 capacity, 0 elements allowed in-flight as a special case&quot; is basic=
ally just an implementation detail of the theory AFAIC. :)</div><div>(But i=
n terms of specifying the runtime semantics and in terms of implementation,=
 it does probably make things simpler to treat that &quot;in-flight&quot; e=
lement specially. I don&#39;t know for sure.)</div><div><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quo=
te"><div> A push operation is blocked (goroutine gets suspended) till anoth=
er goroutine consumes the pushed data; a pop operation will block (suspendi=
ng the goroutine) if no producer is waiting or immediately return otherwise=
..<br>Buffered Go channels are created by specifying a capacity (at least 1)=
 at creation.<br></div></div></div></div></blockquote><div><br></div><div>A=
greed.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>Go channels are per defaul=
t bidirectional (push and pop operations can be invoked on the channel by t=
he same goroutine) but can created as unidirectional: &#39;c chan&lt;- int&=
#39; =3D=3D only push operations on channel c allowed, &#39;c &lt;-chan int=
&#39; =3D=3D only pop operations allowed.<br></div></div></div></div></bloc=
kquote><div><br></div><div>I wasn&#39;t aware of this; thanks!</div><div>No=
tice that invoking push or pop on an &quot;unbuffered&quot; channel confine=
d to a single thread will always deadlock; but Go does allow you to write c=
ode like &quot;ch &lt;- 1; fmt.Println(&lt;-ch)&quot; within a single threa=
d as long as &quot;ch&quot; is buffered.</div><div><br></div><div>I now thi=
nk I was also wrong about their SPSC-ness. Not only can you have multiple &=
quot;handles&quot; to a single conceptual channel, but you can actually acc=
ess a single handle simultaneously via pointers from different threads =E2=
=80=94 which I think is not true of Rust and certainly shouldn&#39;t be tru=
e of C++. (<a href=3D"https://golang.org/ref/mem#tmp_7">The official docs i=
ndicate</a> that you can reliably access a single &quot;chan&quot; object f=
rom multiple goroutines simultaneously, even though <a href=3D"https://gola=
ng.org/doc/faq#atomic_maps">the same is not true of &quot;map&quot;</a>.)</=
div><div>So, revised:</div><div><br></div><div><div><a href=3D"https://tour=
..golang.org/concurrency/2" target=3D"_blank">What Golang calls a &quot;chan=
nel&quot;</a>=C2=A0is a <i>bidirectional MPMC</i> concurrent bounded queue =
with capacity 1, in that reads and writes are guaranteed to block =E2=80=94=
 and again the producer and consumer &quot;ends&quot; are logically separat=
ed. =C2=A0(I intuitively believe that these channels implement the coroutin=
e switching I described above, but I admit I don&#39;t know for sure.)</div=
><div><a href=3D"https://tour.golang.org/concurrency/3" target=3D"_blank">G=
olang also supports &quot;buffered channels&quot;</a>, a.k.a. <i>bidirectio=
nal MPMC</i> concurrent bounded queues of any specified capacity.</div></di=
v><div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><div>What I&#39;m missing?<br>=
=C2=A0</div><span class=3D"gmail-"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote">a misuse of the term &quot=
;channel&quot; as Boost.Fiber&#39;s.<br></div></div></div></blockquote></sp=
an></div><br></div><div class=3D"gmail_extra">in which sense?<br></div></di=
v></blockquote><div><br></div><div>I don&#39;t believe that the term &quot;=
channel&quot; should be used to refer to a &quot;concurrent queue&quot; obj=
ect.=C2=A0 The point of a channel, in my mind, is that it is SPSC and prefe=
rably capacity-1 (or capacity-0 in Go&#39;s terms); this is what lets you m=
ake it fast.=C2=A0 If you add features until you&#39;ve got a bidirectional=
 MPMC concurrent bounded queue =E2=80=94 or in Boost.Fiber&#39;s case a bid=
irectional MPMC concurrent <i>unbounded</i> queue =E2=80=94 then not only d=
o you lose a lot of performance, but you&#39;re just duplicating work that&=
#39;s already been done by queue implementations such as <a href=3D"https:/=
/software.intel.com/en-us/node/506200">TBB</a>.</div><div><br></div><div>At=
 the very least, if you&#39;re designing a data structure whose public API =
is exactly the public API of std::queue, please call it some variation on &=
quot;queue&quot; or &quot;concurrent_queue&quot; so that people can find an=
d understand it!=C2=A0 If you call it &quot;channel&quot;, I for one am goi=
ng to assume that it&#39;s got semantics that are somehow different from a =
queue&#39;s.</div><div><br></div><div>=E2=80=93Arthur</div></div></div></di=
v>

<p></p>

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

--047d7b873a2ce17568053f78264c--

.

--94eb2c0896a059c03e053f79cb93
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2016-10-22 20:16 GMT+02:00 Arthur O'Dwyer <arthur.j.odwyer@gmail.com>:

> I don't believe that the term "channel" should be used to refer to a
> "concurrent queue" object.  The point of a channel, in my mind, is that i=
t
> is SPSC and preferably capacity-1 (or capacity-0 in Go's terms); this is
> what lets you make it fast.  If you add features until you've got a
> bidirectional MPMC concurrent bounded queue =E2=80=94 or in Boost.Fiber's=
 case a
> bidirectional MPMC concurrent *unbounded* queue =E2=80=94 then not only d=
o you
> lose a lot of performance,
>

why must a channel of type SPSC?
the implementation of a capacity-0 channel must not be much different than
a capacity-N channel (see 'Go channels on steroids' from Dmitry Vyukov)


> but you're just duplicating work that's already been done by queue
> implementations such as TBB <https://software.intel.com/en-us/node/506200=
>
> .
>

TBB works very different than boost.fiber (boost.fiber does stack
switching, TBB doesn't) - the TBB queues are completely unaware of the
features a fiber provides
so I think your statement is not valid


> At the very least, if you're designing a data structure whose public API
> is exactly the public API of std::queue, please call it some variation on
> "queue" or "concurrent_queue" so that people can find and understand it!
> If you call it "channel", I for one am going to assume that it's got
> semantics that are somehow different from a queue's.
>

I assume you refer to push()/try_push() ... I believe that thsi API is no
exclusively for queues.

--=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/CA%2Bwfc18zeBgG5%3Dar%3Dk0EeBw-41uOccc5j_oVd_b1f=
ajJfkmfdQ%40mail.gmail.com.

--94eb2c0896a059c03e053f79cb93
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">2016=
-10-22 20:16 GMT+02:00 Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a href=3D"=
mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gmail.c=
om</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr"><span class=3D"gmail-"></span><div class=3D"gmail_quote"><spa=
n class=3D"gmail-"></span><div>I don&#39;t believe that the term &quot;chan=
nel&quot; should be used to refer to a &quot;concurrent queue&quot; object.=
=C2=A0 The point of a channel, in my mind, is that it is SPSC and preferabl=
y capacity-1 (or capacity-0 in Go&#39;s terms); this is what lets you make =
it fast.=C2=A0 If you add features until you&#39;ve got a bidirectional MPM=
C concurrent bounded queue =E2=80=94 or in Boost.Fiber&#39;s case a bidirec=
tional MPMC concurrent <i>unbounded</i> queue =E2=80=94 then not only do yo=
u lose a lot of performance,</div></div></div></blockquote><div><br></div><=
div>why must a channel of type SPSC?<br></div><div>the implementation of a =
capacity-0 channel must not be much different than a capacity-N channel (se=
e &#39;<span class=3D"gmail-c0">Go channels on steroids&#39; from </span><s=
pan class=3D"gmail-c0">Dmitry Vyukov</span>)<br></div><div>=C2=A0</div><blo=
ckquote 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 class=
=3D"gmail_quote"><div> but you&#39;re just duplicating work that&#39;s alre=
ady been done by queue implementations such as <a href=3D"https://software.=
intel.com/en-us/node/506200" target=3D"_blank">TBB</a>.</div></div></div></=
blockquote><div><br></div><div>TBB works very different than boost.fiber (b=
oost.fiber does stack switching, TBB doesn&#39;t)  - the TBB queues are com=
pletely unaware of the features a fiber provides<br></div><div>so I think y=
our statement is not valid<br></div><div>=C2=A0</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 class=3D"gmail_quote"><di=
v></div><div>At the very least, if you&#39;re designing a data structure wh=
ose public API is exactly the public API of std::queue, please call it some=
 variation on &quot;queue&quot; or &quot;concurrent_queue&quot; so that peo=
ple can find and understand it!=C2=A0 If you call it &quot;channel&quot;, I=
 for one am going to assume that it&#39;s got semantics that are somehow di=
fferent from a queue&#39;s.<br></div></div></div></blockquote><div><br></di=
v><div>I assume you refer to push()/try_push() ... I believe that thsi API =
is no exclusively for queues.<br></div></div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc18zeBgG5%3Dar%3Dk0EeBw-41uOcc=
c5j_oVd_b1fajJfkmfdQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc18z=
eBgG5%3Dar%3Dk0EeBw-41uOccc5j_oVd_b1fajJfkmfdQ%40mail.gmail.com</a>.<br />

--94eb2c0896a059c03e053f79cb93--

.

--001a11404660bec5c1053f7a5942
Content-Type: text/plain; charset=UTF-8

2016-10-22 20:16 GMT+02:00 Arthur O'Dwyer <arthur.j.odwyer@gmail.com>:

> You're correct that Golang's own documentation describes its channels as
> "capacity 0"; but in the terminology I was using, that would mean you could
> never put anything into the channel because it would always be full!
> Whether you think of it as "0 capacity, 1 element allowed in-flight as a
> special case" or "1 capacity, 0 elements allowed in-flight as a special
> case" is basically just an implementation detail of the theory AFAIC. :)
>

what about following:
a producer using a channel takes care if the data has been consumed, e.g.
the producer is blocked till a consumer has dequeued producers item.
a producer using a queue doesn't care whether the item was consumed or not.
the producer will only be blocked if the queue is bound and the queue is
full.
maybe this might work to distinguish queues and channels

--
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/CA%2Bwfc1_NyNVBi0Wgr1kUbi7HZoEA-BUBS2L5eseGZ2LMk%2Bbccg%40mail.gmail.com.

--001a11404660bec5c1053f7a5942
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">2016=
-10-22 20:16 GMT+02:00 Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a href=3D"=
mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gmail.c=
om</a>&gt;</span>:<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""></span><div class=3D"gmail_quote"><span class=3D""></span><div>=
You&#39;re correct that Golang&#39;s own documentation describes its channe=
ls as &quot;capacity 0&quot;; but in the terminology I was using, that woul=
d mean you could never put anything into the channel because it would alway=
s be full! Whether you think of it as &quot;0 capacity, 1 element allowed i=
n-flight as a special case&quot; or &quot;1 capacity, 0 elements allowed in=
-flight as a special case&quot; is basically just an implementation detail =
of the theory AFAIC. :)<br></div></div></div></blockquote></div><br></div><=
div class=3D"gmail_extra">what about following:<br></div><div class=3D"gmai=
l_extra">a producer using a channel takes care if the data has been consume=
d, e.g. the producer is blocked till a consumer has dequeued producers item=
..<br></div><div class=3D"gmail_extra">a producer using a queue doesn&#39;t =
care whether the item was consumed or not. the producer will only be blocke=
d if the queue is bound and the queue is full.<br></div><div class=3D"gmail=
_extra">maybe this might work to distinguish queues and channels <br></div>=
</div>

<p></p>

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

--001a11404660bec5c1053f7a5942--

.

------=_Part_2472_727223661.1477174709857
Content-Type: multipart/alternative;
 boundary="----=_Part_2473_1703338764.1477174709857"

------=_Part_2473_1703338764.1477174709857
Content-Type: text/plain; charset=UTF-8

On Friday, October 21, 2016 at 12:37:36 PM UTC-7, Arthur O'Dwyer wrote:
>
> Please remember that the concept Aaron is describing is not a "channel" as
> implemented by Golang <https://tour.golang.org/concurrency/2>, etc.; it's
> a "concurrent bounded queue", as implemented by TBB
> <https://software.intel.com/en-us/node/506200>, Lawrence Crowl's P0260
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0260r0.html>,
> etc.  Let me explain what I'm thinking...
>

Please also remember that we're in C++ and have a type system. The original
problems described are solved via types.

This is exactly why future is split into a future (consumer) and a promise
(producer). It's less error-prone and no less expressive.

There is no reason why a channel/queue/whatever should be different. The
original problems discussed are then solved. A function that produces
values cannot accidentally consume because it has only a
`channel_producer<T>` object that only offers `operator<<`.

If a function needs both ends, it can take both as parameters, or use a
wrapper object, such as a `bichannel<T, U>` that offers `operator<<(T
const&)` and `operator>>(U&)`.

The factory for a channel return both a producer and consumer. The factory
for a bichannel returns both a `bichannel<T, U>` and a `bichannel<U, T>`.

Safe expression of simple concepts that leverages the type system to avoid
errors.

>

--
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/a568d3bb-4f77-4276-9ca3-02c1734c2cd1%40isocpp.org.

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

<div dir=3D"ltr">On Friday, October 21, 2016 at 12:37:36 PM UTC-7, Arthur O=
&#39;Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote"><div>Please remember that the concept A=
aron is describing is not a &quot;channel&quot; as implemented by <a href=
=3D"https://tour.golang.org/concurrency/2" target=3D"_blank" rel=3D"nofollo=
w" onmousedown=3D"this.href=3D&#39;https://tour.golang.org/concurrency/2&#3=
9;;return true;" onclick=3D"this.href=3D&#39;https://tour.golang.org/concur=
rency/2&#39;;return true;">Golang</a>, etc.; it&#39;s a &quot;concurrent bo=
unded queue&quot;, as implemented by <a href=3D"https://software.intel.com/=
en-us/node/506200" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fsoftware.intel.com=
%2Fen-us%2Fnode%2F506200\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHx5yLWz0Hm=
lDt0nXjuwe1EPUdi2A&#39;;return true;" onclick=3D"this.href=3D&#39;https://w=
ww.google.com/url?q\x3dhttps%3A%2F%2Fsoftware.intel.com%2Fen-us%2Fnode%2F50=
6200\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHx5yLWz0HmlDt0nXjuwe1EPUdi2A&#=
39;;return true;">TBB</a>,=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc2=
2/wg21/docs/papers/2016/p0260r0.html" target=3D"_blank" rel=3D"nofollow" on=
mousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fw=
ww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0260r0.html\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHaHOW-8ODAoGhfEoSybUg0_gll9A&#39;;r=
eturn true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhtt=
p%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0=
260r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHaHOW-8ODAoGhfEoSybUg0_g=
ll9A&#39;;return true;">Lawrence Crowl&#39;s=C2=A0P0260</a>, etc.=C2=A0 Let=
 me explain what I&#39;m thinking...</div></div></div></div></blockquote><d=
iv><br></div><div>Please also remember that we&#39;re in C++ and have a typ=
e system. The original problems described are solved via types.</div><div><=
br></div><div>This is exactly why future is split into a future (consumer) =
and a promise (producer). It&#39;s less error-prone and no less expressive.=
</div><div><br></div><div>There is no reason why a channel/queue/whatever s=
hould be different. The original problems discussed are then solved. A func=
tion that produces values cannot accidentally consume because it has only a=
 `channel_producer&lt;T&gt;` object that only offers `operator&lt;&lt;`.</d=
iv><div><br></div><div>If a function needs both ends, it can take both as p=
arameters, or use a wrapper object, such as a `bichannel&lt;T, U&gt;` that =
offers `operator&lt;&lt;(T const&amp;)` and `operator&gt;&gt;(U&amp;)`.</di=
v><div><br></div><div>The factory for a channel return both a producer and =
consumer. The factory for a bichannel returns both a `bichannel&lt;T, U&gt;=
` and a `bichannel&lt;U, T&gt;`.</div><div><br></div><div>Safe expression o=
f simple concepts that leverages the type system to avoid errors.</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">
</blockquote></div>

<p></p>

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

------=_Part_2473_1703338764.1477174709857--

------=_Part_2472_727223661.1477174709857--

.

--001a11449a2e5c76e3053f83153a
Content-Type: text/plain; charset=UTF-8

2016-10-23 0:18 GMT+02:00 Sean Middleditch <sean.middleditch@gmail.com>:

> If a function needs both ends, it can take both as parameters, or use a
> wrapper object, such as a `bichannel<T, U>` that offers `operator<<(T
> const&)` and `operator>>(U&)`.
>

so operator<<() == push() and operator>>() == pop(), that means no
try-push() and try_pop(),.
are operator<<() and operator>>() blocking in general (for instance
producer waits till item has been consumed) or does it block only at the
slow path?

--
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/CA%2Bwfc18%3DH1Rwkjz%3D2Bvy8gVekLXbyyzvq5%3Dvc1cdbPWNqcDO%3DQ%40mail.gmail.com.

--001a11449a2e5c76e3053f83153a
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">2016=
-10-23 0:18 GMT+02:00 Sean Middleditch <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:sean.middleditch@gmail.com" target=3D"_blank">sean.middleditch@gmail.co=
m</a>&gt;</span>:<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""></span><div>If a function needs both ends, it can take both as p=
arameters, or use a wrapper object, such as a `bichannel&lt;T, U&gt;` that =
offers `operator&lt;&lt;(T const&amp;)` and `operator&gt;&gt;(U&amp;)`.<br>=
</div></div></blockquote></div><br></div><div class=3D"gmail_extra">so oper=
ator&lt;&lt;() =3D=3D push() and operator&gt;&gt;() =3D=3D pop(), that mean=
s no try-push() and try_pop(),.<br>are operator&lt;&lt;() and operator&gt;&=
gt;() blocking in general (for instance producer waits till item has been c=
onsumed) or does it block only at the slow path?<br><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc18%3DH1Rwkjz%3D2Bvy8gVekLXbyy=
zvq5%3Dvc1cdbPWNqcDO%3DQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwf=
c18%3DH1Rwkjz%3D2Bvy8gVekLXbyyzvq5%3Dvc1cdbPWNqcDO%3DQ%40mail.gmail.com</a>=
..<br />

--001a11449a2e5c76e3053f83153a--

.

--001a114e63c2f8b490053fa2e3d5
Content-Type: text/plain; charset=UTF-8

On Sun, Oct 23, 2016 at 12:18 AM, Oliver Kowalke <oliver.kowalke@gmail.com>
wrote:

> 2016-10-23 0:18 GMT+02:00 Sean Middleditch <sean.middleditch@gmail.com>:
>
>> If a function needs both ends, it can take both as parameters, or use a
>> wrapper object, such as a `bichannel<T, U>` that offers `operator<<(T
>> const&)` and `operator>>(U&)`.
>>
>
> so operator<<() == push() and operator>>() == pop(), that means no
> try-push() and try_pop(),.
> are operator<<() and operator>>() blocking in general (for instance
> producer waits till item has been consumed) or does it block only at the
> slow path?
>

Just a note, that is a question more to other parts of the thread. I'd
personally prefer push/try_push; I was just using the stream interface
proposed earlier to illustrate an unrelated point. I personally think the
overloaded operators here are bonkers.


>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/PFsRPzrUrJ8/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CA%2Bwfc18%3DH1Rwkjz%
> 3D2Bvy8gVekLXbyyzvq5%3Dvc1cdbPWNqcDO%3DQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc18%3DH1Rwkjz%3D2Bvy8gVekLXbyyzvq5%3Dvc1cdbPWNqcDO%3DQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>



--
Sean Middleditch
http://seanmiddleditch.com

--
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/CALQmNFiPRSL9jCAhi3B3BV1AJrw3bXXG2ZC0qbzVLaUgcJnWwQ%40mail.gmail.com.

--001a114e63c2f8b490053fa2e3d5
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 S=
un, Oct 23, 2016 at 12:18 AM, Oliver Kowalke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:oliver.kowalke@gmail.com" target=3D"_blank">oliver.kowalke@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2016-10-23 0:18 GM=
T+02:00 Sean Middleditch <span dir=3D"ltr">&lt;<a href=3D"mailto:sean.middl=
editch@gmail.com" target=3D"_blank">sean.middleditch@gmail.com</a>&gt;</spa=
n>:<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></span><div>If=
 a function needs both ends, it can take both as parameters, or use a wrapp=
er object, such as a `bichannel&lt;T, U&gt;` that offers `operator&lt;&lt;(=
T const&amp;)` and `operator&gt;&gt;(U&amp;)`.<br></div></div></blockquote>=
</div><br></div><div class=3D"gmail_extra">so operator&lt;&lt;() =3D=3D pus=
h() and operator&gt;&gt;() =3D=3D pop(), that means no try-push() and try_p=
op(),.<br>are operator&lt;&lt;() and operator&gt;&gt;() blocking in general=
 (for instance producer waits till item has been consumed) or does it block=
 only at the slow path?</div></div></blockquote><div><br></div><div>Just a =
note, that is a question more to other parts of the thread. I&#39;d persona=
lly prefer push/try_push; I was just using the stream interface proposed ea=
rlier to illustrate an unrelated point. I personally think the overloaded o=
perators here are bonkers.</div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><span class=3D"HOEnZb"><fo=
nt color=3D"#888888"><br><br></font></span></div></div><span class=3D"HOEnZ=
b"><font color=3D"#888888">

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/PFsRPzrUrJ8/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/P=
FsRPzrUrJ8/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/CA%2Bwfc18%3DH1Rwkjz%3D2Bvy8gVekLXbyy=
zvq5%3Dvc1cdbPWNqcDO%3DQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=
=3Dfooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/=
msgid/std-<wbr>proposals/CA%2Bwfc18%<wbr>3DH1Rwkjz%<wbr>3D2Bvy8gVekLXbyyzvq=
5%<wbr>3Dvc1cdbPWNqcDO%3DQ%40mail.<wbr>gmail.com</a>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r><div class=3D"gmail_signature" data-smartmail=3D"gmail_signature">Sean Mi=
ddleditch<br><a href=3D"http://seanmiddleditch.com" target=3D"_blank">http:=
//seanmiddleditch.com</a></div>
</div></div>

<p></p>

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

--001a114e63c2f8b490053fa2e3d5--

.

--001a113ec86a0be1a2053faabd1d
Content-Type: text/plain; charset=UTF-8

2016-10-24 23:15 GMT+02:00 Sean Middleditch <sean@middleditch.us>:

> On Sun, Oct 23, 2016 at 12:18 AM, Oliver Kowalke <oliver.kowalke@gmail.com
> > wrote:
>
>> 2016-10-23 0:18 GMT+02:00 Sean Middleditch <sean.middleditch@gmail.com>:
>>
>>> If a function needs both ends, it can take both as parameters, or use a
>>> wrapper object, such as a `bichannel<T, U>` that offers `operator<<(T
>>> const&)` and `operator>>(U&)`.
>>>
>>
>> so operator<<() == push() and operator>>() == pop(), that means no
>> try-push() and try_pop(),.
>> are operator<<() and operator>>() blocking in general (for instance
>> producer waits till item has been consumed) or does it block only at the
>> slow path?
>>
>
> Just a note, that is a question more to other parts of the thread. I'd
> personally prefer push/try_push; I was just using the stream interface
> proposed earlier to illustrate an unrelated point. I personally think the
> overloaded operators here are bonkers.
>

Despite of this the question is how queues are distinguished from channels
or is it a synonym for the same object.
A channel is used for synchronization via message passing but a
(concurrent) queue does serve this too.
What about following:
- a concurrent_queue provides asynchronous mp
- a (C++) channel provides synchronous message passing, e.g acts as an
rendezvous point

--
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/CA%2Bwfc1_6mTeZ0ZMtYOG_ift5apSWv%3DTZn3MaUu8jDdCy%3De48%3Dw%40mail.gmail.com.

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

<div dir=3D"ltr"><div><div><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote">2016-10-24 23:15 GMT+02:00 Sean Middleditch <span dir=3D"ltr">&lt;<a =
href=3D"mailto:sean@middleditch.us" target=3D"_blank">sean@middleditch.us</=
a>&gt;</span>:<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"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><div><div class=3D"h5">On Sun,=
 Oct 23, 2016 at 12:18 AM, Oliver Kowalke <span dir=3D"ltr">&lt;<a href=3D"=
mailto:oliver.kowalke@gmail.com" target=3D"_blank">oliver.kowalke@gmail.com=
</a>&gt;</span> 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"><=
div class=3D"gmail_extra"><div class=3D"gmail_quote">2016-10-23 0:18 GMT+02=
:00 Sean Middleditch <span dir=3D"ltr">&lt;<a href=3D"mailto:sean.middledit=
ch@gmail.com" target=3D"_blank">sean.middleditch@gmail.com</a>&gt;</span>:<=
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></span><div>If a f=
unction needs both ends, it can take both as parameters, or use a wrapper o=
bject, such as a `bichannel&lt;T, U&gt;` that offers `operator&lt;&lt;(T co=
nst&amp;)` and `operator&gt;&gt;(U&amp;)`.<br></div></div></blockquote></di=
v><br></div><div class=3D"gmail_extra">so operator&lt;&lt;() =3D=3D push() =
and operator&gt;&gt;() =3D=3D pop(), that means no try-push() and try_pop()=
,.<br>are operator&lt;&lt;() and operator&gt;&gt;() blocking in general (fo=
r instance producer waits till item has been consumed) or does it block onl=
y at the slow path?</div></div></blockquote><div><br></div></div></div><div=
>Just a note, that is a question more to other parts of the thread. I&#39;d=
 personally prefer push/try_push; I was just using the stream interface pro=
posed earlier to illustrate an unrelated point. I personally think the over=
loaded operators here are bonkers.<br></div></div></div></div></blockquote>=
</div><br></div>Despite of this the question is how queues are distinguishe=
d from channels or is it a synonym for the same object.<br></div>A channel =
is used for synchronization via message passing but a (concurrent) queue do=
es serve this too.<br></div>What about following:<br>- a concurrent_queue p=
rovides asynchronous mp<br>- a (C++) channel provides synchronous message p=
assing, e.g acts as an rendezvous point<br></div>

<p></p>

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

--001a113ec86a0be1a2053faabd1d--

.

------=_Part_5546_267251828.1477499832260
Content-Type: multipart/alternative;
 boundary="----=_Part_5547_580555407.1477499832260"

------=_Part_5547_580555407.1477499832260
Content-Type: text/plain; charset=UTF-8

There has been a lot of comments about Promises/Futures in this proposal. I
can't stress enough that Promises/Futures are solving a different problem
and not related to channels, although they can be used to create more
complex solutions. Channels give a guarantee that they will block when
requesting data but the channel does not have data this is the intent.
Returning a Promise breaks that fundamental model. However, there is
nothing saying you can't have a channel of Promises/Futures, that is
definitely possibly, but goes against the intent of CSP.

Go does _not_ have first class support for unidirectional channels - that
is a mechanism that built on top of the type system, not channels. All
channels in Go are bidirectional, it is the type system that allows the
channel to be limited to one direction or another. Following that logic the
base channel implementation is bidirectional and subclasses can be created
to limit the direction. I am working on restructuring some of the types to
make this possible - I have pushed another branch with an example of a read
or write channel.

Based on previous proposals and reading a lot of the minutes from the
committee, implementation isn't what is accepted/rejected, but
API/functionality. The example implementation does use a queue, but that
isn't really relevant to the proposal, the concept being proposed is a
channel type which has very specific semantics to a lot of people outside
C++.

This proposal is very much intended to be a way to allow current non-C++
developers to feel comfortable with moving to C++ since it would now have a
channel primitive in the library. It is/was _not_ my intent to redefine the
basic channel concept, which is preserved with the current proposal, for
C++.

All that being said, based on this conversation I am seeing a few things
emerging:

1) The C++ community views the channel concept a bit differently
2) Channel behavior - as defined in CSP - may not be a good fit for C++
since there are other solutions
3) There maybe interest in a channel-esque solution, but it may need to be
less abstract and more explicit
4) My core understanding of how the broader community views channels is
wrong - I must accept this as a possibility; however, I have been doing
work with channels for several years now and implemented them several times
in various higher level languages. Therefore, I don't think that is the
case, but I could have been doing this wrong for years :)

arr

--
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/13bd6e8f-57c6-44b5-95cf-b1c1b7c5a19a%40isocpp.org.

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

<div dir=3D"ltr"><div>There has been a lot of comments about Promises/Futur=
es in this proposal. I can&#39;t stress enough that Promises/Futures are so=
lving a different problem and not related to channels, although they can be=
 used to create more complex solutions. Channels give a guarantee that they=
 will block when requesting data but the channel does not have data this is=
 the intent. Returning a Promise breaks that fundamental model. However, th=
ere is nothing saying you can&#39;t have a channel of Promises/Futures, tha=
t is definitely possibly, but goes against the intent of CSP.</div><div><br=
></div><div>Go does _not_ have first class support for unidirectional chann=
els - that is a mechanism that built on top of the type system, not channel=
s. All channels in Go are bidirectional, it is the type system that allows =
the channel to be limited to one direction or another. Following that logic=
 the base channel implementation is bidirectional and subclasses can be cre=
ated to limit the direction. I am working on restructuring some of the type=
s to make this possible - I have pushed another branch with an example of a=
 read or write channel.</div><div><br></div><div>Based on previous proposal=
s and reading a lot of the minutes from the committee, implementation isn&#=
39;t what is accepted/rejected, but API/functionality. The example implemen=
tation does use a queue, but that isn&#39;t really relevant to the proposal=
, the concept being proposed is a channel type which has very specific sema=
ntics to a lot of people outside C++.</div><div><br></div><div>This proposa=
l is very much intended to be a way to allow current non-C++ developers to =
feel comfortable with moving to C++ since it would now have a channel primi=
tive in the library. It is/was _not_ my intent to redefine the basic channe=
l concept, which is preserved with the current proposal, for C++.</div><div=
><br></div><div>All that being said, based on this conversation I am seeing=
 a few things emerging:</div><div><br></div><div>1) The C++ community views=
 the channel concept a bit differently=C2=A0</div><div>2) Channel behavior =
- as defined in CSP - may not be a good fit for C++ since there are other s=
olutions</div><div>3) There maybe interest in a channel-esque solution, but=
 it may need to be less abstract and more explicit</div><div>4) My core und=
erstanding of how the broader community views channels is wrong - I must ac=
cept this as a possibility; however, I have been doing work with channels f=
or several years now and implemented them several times in various higher l=
evel languages. Therefore, I don&#39;t think that is the case, but I could =
have been doing this wrong for years :)</div><div><br></div><div>arr</div><=
/div>

<p></p>

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

------=_Part_5547_580555407.1477499832260--

------=_Part_5546_267251828.1477499832260--

.

------=_Part_4327_420292250.1477507410898
Content-Type: multipart/alternative;
 boundary="----=_Part_4328_194344827.1477507410898"

------=_Part_4328_194344827.1477507410898
Content-Type: text/plain; charset=UTF-8

On Monday, October 24, 2016 at 11:37:14 PM UTC-7, Oliver Kowalke wrote:
>
> Despite of this the question is how queues are distinguished from channels
> or is it a synonym for the same object.
> A channel is used for synchronization via message passing but a
> (concurrent) queue does serve this too.
> What about following:
> - a concurrent_queue provides asynchronous mp
> - a (C++) channel provides synchronous message passing, e.g acts as an
> rendezvous point
>

This is how channels have always worked in my mind. I usually refer to them
as a 'synchronization point' but 'rendezvous point' is also a great
description. This is why they are so fundamentally different from
Promises/Futures. When a thread accesses a channel it only returns if there
is data or a 'message'. Sending through a channel can be the same but
internally it can __optionally__ buffer, but by default - see reference
implementation, it is blocking.

arr

--
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/ca88e4a2-6a01-4656-97c7-429e6132861e%40isocpp.org.

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

<div dir=3D"ltr">On Monday, October 24, 2016 at 11:37:14 PM UTC-7, Oliver K=
owalke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><div>Despite of this the question is how queues are distinguished from=
 channels or is it a synonym for the same object.<br></div>A channel is use=
d for synchronization via message passing but a (concurrent) queue does ser=
ve this too.<br></div>What about following:<br>- a concurrent_queue provide=
s asynchronous mp<br>- <span style=3D"background-color: rgb(255, 255, 0);">=
a (C++) channel provides synchronous message passing, e.g acts as an rendez=
vous point</span><br></div></blockquote><div><br></div><div>This is how cha=
nnels have always worked in my mind. I usually refer to them as a &#39;sync=
hronization point&#39; but &#39;rendezvous point&#39; is also a great descr=
iption. This is why they are so fundamentally different from Promises/Futur=
es. When a thread accesses a channel it only returns if there is data or a =
&#39;message&#39;. Sending through a channel can be the same but internally=
 it can __optionally__ buffer, but by default - see reference implementatio=
n, it is blocking.</div><div><br></div><div>arr</div></div>

<p></p>

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

------=_Part_4328_194344827.1477507410898--

------=_Part_4327_420292250.1477507410898--

.

--001a113f26761e9570053fc920da
Content-Type: text/plain; charset=UTF-8

2016-10-26 18:37 GMT+02:00 Aaron R Robinson <linuxuser27@gmail.com>:

> There has been a lot of comments about Promises/Futures in this proposal.
> I can't stress enough that Promises/Futures are solving a different problem
> and not related to channels, although they can be used to create more
> complex solutions. Channels give a guarantee that they will block when
> requesting data but the channel does not have data this is the intent.
> Returning a Promise breaks that fundamental model. However, there is
> nothing saying you can't have a channel of Promises/Futures, that is
> definitely possibly, but goes against the intent of CSP.
>

I'm still trying to understand the rationale behind the channel concept
that you are proposing (in the meantime I've also had some time to look at
John Bandela's talk from CppCon).

From my perspective future/promise combo (and let's ignore the
implementation in c++ and just consider the conceptual working of what I
believe the combo does) is that you request a task to be done (don't care
where) and expect the result. If task executor is a different thread then
it's possible that when I request the result of the task on the other side,
the task will already be finished and even block-until-task-is-finished
(wait) on future doesn't block. If it's run on the same thread it has time
to execute in entirety if I call wait or in part and then return control
back to me (the owner of the future) until I call wait-for-a-while
(wait_for, wait_until) on future again - I know that this isn't how c++
future/promise are implemented but when I was forced to write a single
threaded library (long story) I used future/promise api as the interface
with the hope that some day I'll be able to persuade the
no-threads-believer into switching to c++ future/promise and using multiple
threads without changes to the rest of the code (except recompile).

The point being that moving data from point a to point b or task delegation
can be viewed as one and the same (you give data somewhere -> you're
feeding the task; you expect data from somewhere -> you are waiting for the
task of retrieving data to complete) and I see no benefit of enforcing that
the one that is waiting for the data must block (he may block or check from
time to time and do some other stuff in the meantime - it depends on the
situation and the task that we're trying to solve).

So when you are talking about blocking bidirectional channel in my head it
sounds "a nice interface for a callback function or coroutines" but since
your code uses >> and << operators and not the start of the function I'm
guessing that callback is out of the question and since the code must
somehow come to both operators I'm guessing either multiple threads (where
I don't understand why you'd force block - block by choice OK but why
force?) or coroutines (where I don't exactly understand what benefit the
channel brings - but it's true that I've never used coroutines).

And at this point I get to the problem that I still don't understand what
the difference between your proposed channel and future/promise is (they
both can - and in case of channel must - block while waiting for data/task
completion). What would be fundamentally different from future/promise
would be guarantee to block the sender until the receiver reads the data
(in future/promise you block the receiver until the sender sends the data)
but with my current understanding that isn't the case - I might be mistaken
and you are talking about exactly that.

As far as my mental model goes I see channels as future/promise
combinations where you can receive data from future as often as you'd like
and put data in promise as often as you like (where it blocks if the data
buffer is full) and nothing more. For me the api of future/promise is good
enough (minus missing "then" and other extensions) but since I've heard
quite allot about performance issues there might be something wrong with
that api that I don't know about (but I'm guessing that it's more related
to implementation restrictions than the api itself - but I might be wrong).

So the bottom line is that I still can't imagine how the proposed channel
would bring me some benefits and make my life easier when thinking about
and implementing solutions to certain problem types.

Regards,
Domen

--
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/CAKgx6BL%2BYRuo0uGSbz9GE2EDgF0%2BU1Ld6X61CpFk%3D2tQ0JFyeg%40mail.gmail.com.

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

<div dir=3D"ltr">2016-10-26 18:37 GMT+02:00 Aaron R Robinson <span dir=3D"l=
tr">&lt;<a href=3D"mailto:linuxuser27@gmail.com" target=3D"_blank">linuxuse=
r27@gmail.com</a>&gt;</span>:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><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"l=
tr"><div>There has been a lot of comments about Promises/Futures in this pr=
oposal. I can&#39;t stress enough that Promises/Futures are solving a diffe=
rent problem and not related to channels, although they can be used to crea=
te more complex solutions. Channels give a guarantee that they will block w=
hen requesting data but the channel does not have data this is the intent. =
Returning a Promise breaks that fundamental model. However, there is nothin=
g saying you can&#39;t have a channel of Promises/Futures, that is definite=
ly possibly, but goes against the intent of CSP.</div></div></blockquote><b=
r></div><div class=3D"gmail_quote">I&#39;m still trying to understand the r=
ationale behind the channel concept that you are proposing (in the meantime=
 I&#39;ve also had some time to look at John Bandela&#39;s talk from CppCon=
).<br><br></div><div class=3D"gmail_quote">From my perspective future/promi=
se combo (and let&#39;s ignore the implementation in c++ and just consider =
the conceptual working of what I believe the combo does) is that you reques=
t a task to be done (don&#39;t care where) and expect the result. If task e=
xecutor is a different thread then it&#39;s possible that when I request th=
e result of the task on the other side, the task will already be finished a=
nd even block-until-task-is-finished (wait) on future doesn&#39;t block. If=
 it&#39;s run on the same thread it has time to execute in entirety if I ca=
ll wait or in part and then return control back to me (the owner of the fut=
ure) until I call wait-for-a-while (wait_for, wait_until) on future again -=
 I know that this isn&#39;t how c++ future/promise are implemented but when=
 I was forced to write a single threaded library (long story) I used future=
/promise api as the interface with the hope that some day I&#39;ll be able =
to persuade the no-threads-believer into switching to c++ future/promise an=
d using multiple threads without changes to the rest of the code (except re=
compile).<br><br></div><div class=3D"gmail_quote">The point being that movi=
ng data from point a to point b or task delegation can be viewed as one and=
 the same (you give data somewhere -&gt; you&#39;re feeding the task; you e=
xpect data from somewhere -&gt; you are waiting for the task of retrieving =
data to complete) and I see no benefit of enforcing that the one that is wa=
iting for the data must block (he may block or check from time to time and =
do some other stuff in the meantime - it depends on the situation and the t=
ask that we&#39;re trying to solve).<br><br></div><div class=3D"gmail_quote=
">So when you are talking about blocking bidirectional channel in my head i=
t sounds &quot;a nice interface for a callback function or coroutines&quot;=
 but since your code uses &gt;&gt; and &lt;&lt; operators and not the start=
 of the function I&#39;m guessing that callback is out of the question and =
since the code must somehow come to both operators I&#39;m guessing either =
multiple threads (where I don&#39;t understand why you&#39;d force block - =
block by choice OK but why force?) or coroutines (where I don&#39;t exactly=
 understand what benefit the channel brings - but it&#39;s true that I&#39;=
ve never used coroutines).<br><br></div><div class=3D"gmail_quote">And at t=
his point I get to the problem that I still don&#39;t understand what the d=
ifference between your proposed channel and future/promise is (they both ca=
n - and in case of channel must - block while waiting for data/task complet=
ion). What would be fundamentally different from future/promise would be gu=
arantee to block the sender until the receiver reads the data (in future/pr=
omise you block the receiver until the sender sends the data) but with my c=
urrent understanding that isn&#39;t the case - I might be mistaken and you =
are talking about exactly that.<br><br></div><div class=3D"gmail_quote">As =
far as my mental model goes I see channels as future/promise combinations w=
here you can receive data from future as often as you&#39;d like and put da=
ta in promise as often as you like (where it blocks if the data buffer is f=
ull) and nothing more. For me the api of future/promise is good enough (min=
us missing &quot;then&quot; and other extensions) but since I&#39;ve heard =
quite allot about performance issues there might be something wrong with th=
at api that I don&#39;t know about (but I&#39;m guessing that it&#39;s more=
 related to implementation restrictions than the api itself - but I might b=
e wrong).<br><br></div><div class=3D"gmail_quote">So the bottom line is tha=
t I still can&#39;t imagine how the proposed channel would bring me some be=
nefits and make my life easier when thinking about and implementing solutio=
ns to certain problem types.<br></div><div class=3D"gmail_quote"><br></div>=
<div class=3D"gmail_quote">Regards,<br></div><div class=3D"gmail_quote">Dom=
en<br></div><br></div></div>

<p></p>

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

--001a113f26761e9570053fc920da--

.

------=_Part_2568_834190357.1477964113001
Content-Type: multipart/alternative;
 boundary="----=_Part_2569_920404664.1477964113001"

------=_Part_2569_920404664.1477964113001
Content-Type: text/plain; charset=UTF-8

Thanks for the feedback Domen.

On Wednesday, October 26, 2016 at 11:52:24 AM UTC-7, Domen Vrankar wrote:
>
> So the bottom line is that I still can't imagine how the proposed channel
> would bring me some benefits and make my life easier when thinking about
> and implementing solutions to certain problem types.
>

I think the above statement is really important and probably were a lot of
confusion is coming from. The slew of use cases you provide all have one
thing in common and that is the threading model is always implied.
Futures/Promises/coroutines, all of them have an implied concurrency
concept that in most cases is non-trivial to break out of. The channel type
is much more akin to a mutex then it is to a Future or Promise as it is
merely a synchronization primitive that allows multiple
threads/coroutines/processes/etc to coordinate in a unified manner. In fact
in the CSP model the term processes is used, not threads. In Limbo you
could communicate through a channel with other processes or spawned
threads. They were all treated equally and this allowed a large amount of
flexibility since it was irrelevant what was on the other end of the
channel, just that when you read from a channel either you waited or were
given data/message.

I think have a channel of Futures is just fine, i don't think it is the
best approach but it could work if you spun up a bunch of light weight
coroutines - John Bandela's talk - and waited for one of them. I don't see
a fundamental reason why that is bad other than the complexity of
determining i have too many futures now and I need another consumer to
handle them. But honestly that isn't really the point. The channel can be
used for the currently popular Promise/Future approach or adopt to using
other concurrency models like Go or Limbo has.

arr

--
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/f7265dc6-6e0e-461f-93e4-9ffa42e0d2cf%40isocpp.org.

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

<div dir=3D"ltr">Thanks for the feedback Domen.<br><br>On Wednesday, Octobe=
r 26, 2016 at 11:52:24 AM UTC-7, Domen Vrankar wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote">So =
the bottom line is that I still can&#39;t imagine how the proposed channel =
would bring me some benefits and make my life easier when thinking about an=
d implementing solutions to certain problem types.</div></div></div></block=
quote><div><br></div><div>I think the above statement is really important a=
nd probably were a lot of confusion is coming from. The slew of use cases y=
ou provide all have one thing in common and that is the threading model is =
always implied. Futures/Promises/coroutines, all of them have an implied co=
ncurrency concept that in most cases is non-trivial to break out of. The ch=
annel type is much more akin to a mutex then it is to a Future or Promise a=
s it is merely a synchronization primitive that allows multiple threads/cor=
outines/processes/etc to coordinate in a unified manner. In fact in the CSP=
 model the term processes is used, not threads. In Limbo you could communic=
ate through a channel with other processes or spawned threads. They were al=
l treated equally and this allowed a large amount of flexibility since it w=
as irrelevant what was on the other end of the channel, just that when you =
read from a channel either you waited or were given data/message.</div><div=
><br></div><div>I think have a channel of Futures is just fine, i don&#39;t=
 think it is the best approach but it could work if you spun up a bunch of =
light weight coroutines - John Bandela&#39;s talk - and waited for one of t=
hem. I don&#39;t see a fundamental reason why that is bad other than the co=
mplexity of determining i have too many futures now and I need another cons=
umer to handle them. But honestly that isn&#39;t really the point. The chan=
nel can be used for the currently popular Promise/Future approach or adopt =
to using other concurrency models like Go or Limbo has.</div><div><br></div=
><div>arr</div></div>

<p></p>

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

------=_Part_2569_920404664.1477964113001--

------=_Part_2568_834190357.1477964113001--

.

--001a1144cfb039ab1505403d8390
Content-Type: text/plain; charset=UTF-8

2016-11-01 2:35 GMT+01:00 Aaron R Robinson <linuxuser27@gmail.com>:

> Thanks for the feedback Domen.
>
> On Wednesday, October 26, 2016 at 11:52:24 AM UTC-7, Domen Vrankar wrote:
>>
>> So the bottom line is that I still can't imagine how the proposed channel
>> would bring me some benefits and make my life easier when thinking about
>> and implementing solutions to certain problem types.
>>
>
> I think the above statement is really important and probably were a lot of
> confusion is coming from.
>

Yes that's true. It might be just me but would appreciate it if there were
some more motivation examples and comparison why that is better to the
alternative (future/promise) api.


> The slew of use cases you provide all have one thing in common and that is
> the threading model is always implied. Futures/Promises/coroutines, all of
> them have an implied concurrency concept that in most cases is non-trivial
> to break out of. The channel type is much more akin to a mutex then it is
> to a Future or Promise as it is merely a synchronization primitive that
> allows multiple threads/coroutines/processes/etc to coordinate in a
> unified manner. In fact in the CSP model the term processes is used, not
> threads. In Limbo you could communicate through a channel with other
> processes or spawned threads. They were all treated equally and this
> allowed a large amount of flexibility since it was irrelevant what was on
> the other end of the channel, just that when you read from a channel either
> you waited or were given data/message.
>

I don't agree with that - your channel api proposal is just a subset of
future/promise api (the wait functionality). I don't have a problem with
the proposed idea but rather have a problem with the proposed api.

What I'm talking about is keeping the future/promise api but different
internal implementations:

1. (current future/promise implementation) you have two threads - you give
a promise to second thread, on first thread you either block by calling
wait or keep doing other things and calling wait_for from time to time.
Promise can only be set once and future can only be read from once.

The rest of the implementations is not in the standard. (I'm also giving
examples with callbacks as I have experience with those but I'm assuming
that they could be replaced by coroutines without a problem.)

2. You have a single thread. You create a future with a callback function.
When you need the value you call the wait function or you keep doing other
things and calling wait_for from time to time and allow the callback to
work for a little while until it is done (time sharing). In this case
future must be able to allow a callback function to the promise holder to
be executed and coincidentally that callback is also the one that
calculates the value that should be put into promise.

3. You create a future that spawns a process and that process returns a
value on finish. Once again you can either wait for the process or do
something else - it's once again the future's owner decision.

4. You extend future/promise pair with a shared state that holds a for e.g.
std::queue of variants (holding either return value or exception) and give
the promise to:
a) a different thread,
b) a callback function (function produces results in a loop),
c) a different process (process returns multiple results in a loop via std
out pipe)
And they only block when shared state queue limit of results is reached (in
this case you would need to extend the promise api to additionally have
try_set_value and try_set_exception that don't block and instead allow the
promise holder to save the value to its storage and try again later if
shared state queue is full).
And on the other side the future doesn't care where the values came from
(different thread, callback, different process) - that info is needed only
during future/promise pair construction and in internal implementation.
Future api also has to be extended with a function that tells it that
promise was destroyed as exceptions might only be forwarded for a certain
error event that doesn't necessarily indicate that we can't get the next
value from that promise without exception (of course a different error
reporting mechanism that doesn't involve exceptions could be used - e.g.
has_error_value/get_error_value functions).

5. Now that you have a queue of multiple values/exceptions you can create
multiple futures and/or that are distributed to different places and can
process the data concurrently without knowing that others can get the data
or put the data in queue (not a problem to add an additional producer or
consumer - one on a different thread, one in a different process and one on
a different pc all together as none of the existent futures/promises need
to know about that new connection).

For me a channel is a communication tunnel to a different
location/locations about which I as the producer or consumer don't want to
care about where they reside (a different function can establish that
connection and it's its responsibility to know where the connection went)
but I want to be able to sent the data through multiple times (unlike
current future/promise implementation in the standard), read on multiple
locations and definitely don't want to be told to whether to block or not.
Your proposed api contains >> and << which for me are just operators that
can be used instead of future/promise wait/get and set_value and are
therefore only a convenience for a narrow use case of channels
communication.

As I already said I like the proposal of channels but see them as change to
future/promise internal implementation and not as something completely
different.

Now I'd really be interested how your api and mental model differs from a
bit extended future/promise api (with most of the changes in the internal
implementation part) and which cases would be simpler/more optimal with
your proposed api.

Thanks,
Domen

--
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/CAKgx6BK4cZ_w1PwLRLPorYfBnB3eaxYwjW5H6a%2Bi_hEZMKwNZA%40mail.gmail.com.

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

<div dir=3D"ltr">2016-11-01 2:35 GMT+01:00 Aaron R Robinson <span dir=3D"lt=
r">&lt;<a href=3D"mailto:linuxuser27@gmail.com" target=3D"_blank">linuxuser=
27@gmail.com</a>&gt;</span>:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><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"lt=
r">Thanks for the feedback Domen.<span class=3D"gmail-"><br><br>On Wednesda=
y, October 26, 2016 at 11:52:24 AM UTC-7, Domen Vrankar wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gm=
ail_quote">So the bottom line is that I still can&#39;t imagine how the pro=
posed channel would bring me some benefits and make my life easier when thi=
nking about and implementing solutions to certain problem types.</div></div=
></div></blockquote><div><br></div></span><div>I think the above statement =
is really important and probably were a lot of confusion is coming from. </=
div></div></blockquote><div><br></div><div>Yes that&#39;s true. It might be=
 just me but would appreciate it if there were some more motivation example=
s and comparison why that is better to the alternative (future/promise) api=
..<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><div>The slew of use cases you provide all have one thi=
ng in common and that is the threading model is always implied. Futures/Pro=
mises/coroutines, all of them have an implied concurrency concept that in m=
ost cases is non-trivial to break out of. The channel type is much more aki=
n to a mutex then it is to a Future or Promise as it is merely a synchroniz=
ation primitive that allows multiple threads/coroutines/processes/<wbr>etc =
to coordinate in a unified manner. In fact in the CSP model the term proces=
ses is used, not threads. In Limbo you could communicate through a channel =
with other processes or spawned threads. They were all treated equally and =
this allowed a large amount of flexibility since it was irrelevant what was=
 on the other end of the channel, just that when you read from a channel ei=
ther you waited or were given data/message.</div></div></blockquote><div><b=
r></div><div>I don&#39;t agree with that - your channel api proposal is jus=
t a subset of future/promise api (the wait functionality). I don&#39;t have=
 a problem with the proposed idea but rather have a problem with the propos=
ed api.<br><br></div><div>What I&#39;m talking about is keeping the future/=
promise api but different internal implementations:<br><br></div><div>1. (c=
urrent future/promise implementation) you have two threads - you give a pro=
mise to second thread, on first thread you either block by calling wait or =
keep doing other things and calling wait_for from time to time. Promise can=
 only be set once and future can only be read from once.<br><br></div><div>=
The rest of the implementations is not in the standard. (I&#39;m also givin=
g examples with callbacks as I have experience with those but I&#39;m assum=
ing that they could be replaced by coroutines without a problem.)<br><br></=
div><div>2. You have a single thread. You create a future with a callback f=
unction. When you need the value you call the wait function or you keep doi=
ng other things and calling wait_for from time to time and allow the callba=
ck to work for a little while until it is done (time sharing). In this case=
 future must be able to allow a callback function to the promise holder to =
be executed and coincidentally that callback is also the one that calculate=
s the value that should be put into promise.<br><br></div><div>3. You creat=
e a future that spawns a process and that process returns a value on finish=
.. Once again you can either wait for the process or do something else - it&=
#39;s once again the future&#39;s owner decision.<br></div><div><br></div><=
div>4. You extend future/promise pair with a shared state that holds a for =
e.g. std::queue of variants (holding either return value or exception) and =
give the promise to:<br></div><div>a) a different thread,<br></div><div>b) =
a callback function (function produces results in a loop),<br></div><div>c)=
 a different process (process returns multiple results in a loop via std ou=
t pipe)<br></div><div>And they only block when shared state queue limit of =
results is reached (in this case you would need to extend the promise api t=
o additionally have try_set_value and try_set_exception that don&#39;t bloc=
k and instead allow the promise holder to save the value to its storage and=
 try again later if shared state queue is full).<br></div><div>And on the o=
ther side the future doesn&#39;t care where the values came from (different=
 thread, callback, different process) - that info is needed only during fut=
ure/promise pair construction and in internal implementation. Future api al=
so has to be extended with a function that tells it that promise was destro=
yed as exceptions might only be forwarded for a certain error event that do=
esn&#39;t necessarily indicate that we can&#39;t get the next value from th=
at promise without exception (of course a different error reporting mechani=
sm that doesn&#39;t involve exceptions could be used - e.g. has_error_value=
/get_error_value functions).<br><br></div><div>5. Now that you have a queue=
 of multiple values/exceptions you can create multiple futures and/or that =
are distributed to different places and can process the data concurrently w=
ithout knowing that others can get the data or put the data in queue (not a=
 problem to add an additional producer or consumer - one on a different thr=
ead, one in a different process and one on a different pc all together as n=
one of the existent futures/promises need to know about that new connection=
).<br><br></div><div>For me a channel is a communication tunnel to a differ=
ent location/locations about which I as the producer or consumer don&#39;t =
want to care about where they reside (a different function can establish th=
at connection and it&#39;s its responsibility to know where the connection =
went) but I want to be able to sent the data through multiple times (unlike=
 current future/promise implementation in the standard), read on multiple l=
ocations and definitely don&#39;t want to be told to whether to block or no=
t. Your proposed api contains &gt;&gt; and &lt;&lt; which for me are just o=
perators that can be used instead of future/promise wait/get and set_value =
and are therefore only a convenience for a narrow use case of channels comm=
unication.<br><br></div><div>As I already said I like the proposal of chann=
els but see them as change to future/promise internal implementation and no=
t as something completely different.<br><br>Now I&#39;d really be intereste=
d how your api and mental model differs from a bit extended future/promise =
api (with most of the changes in the internal implementation part) and whic=
h cases would be simpler/more optimal with your proposed api.<br></div><div=
><br></div><div>Thanks,<br></div><div>Domen<br></div><div><br></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKgx6BK4cZ_w1PwLRLPorYfBnB3eaxYwjW5H=
6a%2Bi_hEZMKwNZA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKgx6BK4cZ_w1P=
wLRLPorYfBnB3eaxYwjW5H6a%2Bi_hEZMKwNZA%40mail.gmail.com</a>.<br />

--001a1144cfb039ab1505403d8390--

.