[rplnt]

> user code could simulate non-deterministic

I'm curious how?

> Not vice versa

There are pretty common patterns for this. At least for real word cases where you might have one special channel that you always want to check. Ugly, but in relation to the previous question, I don't see how one is doable and one isn't?

[tapirl]

> > user code could simulate non-deterministic

> I'm curious how?

    if rand.Intn(2) == 0 {
        select {
           case: <-chan2_whichItreatTheSameAsChan3 // a higher priority
           case: 0xFF ->chan3_whichItreatTheSameAsChan2
        }
    } else {
        select {
           case: 0xFF ->chan3_whichItreatTheSameAsChan2 // a higher priority
           case: <-chan2_whichItreatTheSameAsChan3
        }
    }

Yes, it increases verbosity to the other way, but no performance loss.

[morelisp]

How in the world is generating a random number and branching and doubling the number of instructions "no performance loss"?

[tapirl]

Now the non-deterministic implementation does more work than a deterministic implementation. It generates a random number and sorts the branches. The latter (sorts the branches) is not needed in the above pseudo code.

Doubling the number of instructions has no impact on run-time performance.

And there are more optimization opportunities in implementing a deterministic design. Now, the non-deterministic implementation needs to lock all involved channels before subsequent handling, a deterministic implementation might not need to.