On Sunday, 28 August 2016 17:33:10 UTC+2, Jan Mercl wrote:
>
> Using len(ch) like this in a concurrency scenario is a big no because then
> the value you get carries 0 bits of useful information. It's not a data
> race, it's worse, the race is semantic and not fixable without removing the
> use
Thanks for comments. The status00 should be not-buffered (status00 =
make(chan *Data)); was rate limiting on two channels.
On Sunday, August 28, 2016 at 8:16:50 PM UTC+4:30, Henrik Johansson wrote:
>
> The race is between the len call and the use of the channel. Entries can
> have been added in
The race is between the len call and the use of the channel. Entries can
have been added in between.
On Sun, Aug 28, 2016, 17:40 dc0d wrote:
> Would you please elaborate on that?
>
> As I understand it there is no concurrent use of len happening here. It's
> a for loop and all calling to len is
TLDR; channels, like maps, are references to the a data structure stored
elsewhere. Calling Len on either returns the length of the data stored in the
underlying channel. This is different to a slice, which is a three word value,
containing it's own Len and cap values.
As Jan notes, Len(ch) is
Would you please elaborate on that?
As I understand it there is no concurrent use of len happening here. It's a
for loop and all calling to len is happening sequentially. Unless the
channels make the code inside cases of one select statement concurrent -
which will be super confusing for me.
O
Using len(ch) like this in a concurrency scenario is a big no because then
the value you get carries 0 bits of useful information. It's not a data
race, it's worse, the race is semantic and not fixable without removing the
use of len(ch).
On Sun, Aug 28, 2016, 17:26 dc0d wrote:
> TL;DR
>
> Does
TL;DR
Does assigning a (buffered) channel, already in a variable, to a second
variable, affects the result of len function?
Long version:
What is happening here? - Code at the end; Go 1.7.
*Output 1*:
Nine times:
[ info ] 2016/08/28 19:51:28 LEN_BEFORE=0
[
