You need to code it knowing that either can occur in any order.

> On Sep 8, 2019, at 10:14 AM, changkun <euryugas...@gmail.com> wrote:
> 
> Hi, golang nuts,
> 
> Let's think about this snippet: https://play.golang.org/p/3cNGho3gWTG
> 
> In the code snippet, a ticker is activating and another that that is closing, 
> it seems that they can happen concurrently and result 
> in two different outcomes: either ticker case being executed first or the 
> other way around.
> It is because of the pseudo-randomization of the select statement.
> 
> Intuitively, the close statement should happens-before select statement that 
> starts choosing which case 
> should be executing, and select a closed channel with the highest priority to 
> prevent another receive case being executed once more.
> 
> My questions are:
> Does the Go team or anybody else think of this memory order before? What was 
> the decision that didn't make it?
> If not, is it worth to be defined within the language? There are no language 
> changes and only affects the runtime implementation.
> 
> 
> 
> 
> -- 
> 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 to golang-nuts+unsubscr...@googlegroups.com 
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/6992b605-ff10-4659-8016-dd96066d4588%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/6992b605-ff10-4659-8016-dd96066d4588%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
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 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/254CA3F1-CBFA-4766-88D8-E317007BB61B%40ix.netcom.com.

Reply via email to