> If you want to make it possible, it's pretty easy: 

Thank you for fifth copy of almost same code. I clearly have no enough 
experience to use close of channel and `sync.Once`.
Do you really think so?

> There's another idiom I quite like for futures (when there's only one 
possible source of the value) putting the value back after 
taking it out: 

And that is really broken idiom. It has race condition: concurrent goroutine 
may put dufferent value in the channel between those two lines of code. More 
over, if you use blocking send here, then you will end in blocked goroutine in 
this case.
Another mistake in this idiom: if other concurrent goroutine checks this 
channel within select, and that check happens between those two lines (between 
receive and following send), then it see empty "future".
And even ir when does not lead to mistake, it serialize "broadcast": goroutines 
are awoken one after other, instead of being awoken in parallel.

That is why I want language (or standard library) to have reliable 
implementation:  people should not invent bicycles with square wheels.

You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to