On Saturday, October 5, 2019 at 6:28:37 AM UTC-4, ohir wrote:
> On Fri, 4 Oct 2019 15:15:30 -0700 (PDT) 
> T L <tapi...@gmail.com <javascript:>> wrote: 
> > > If your out <-v must be dependent of ctx.Done not being ready you 
> > > must resolve this dependency by other means. Eg. by selecting for it 
> > > in separate select before. 
> > >   
> > It is not a must. It just tries to select ctx.Done if possible. 
> > In fact, if the two evens are independent with each other, 
> > there is no way to absolutely ensure the must. 
> If it is not a must, then introducing an order at best is void (of no use) 
> at worst it makes sure for a race condition by its very presence. 
> For coming together events A and B that are independent: 
> - proceeding them in either order A, B or in order B, A should result 
> in the same final state as if they came in said order. Hence select's 
> case ordering is unnecessary. 
> - otherwise (that final state depends on order) we have a dependency and 
> the 
> select switch, by language design, is not the right construct to write 
> this 
> dependency down. 
> FYI, AFAIR: the "1+default" select case is optimized by the compiler, so 
> now it is more 
> efficient to have "priority" written explicit than to have more than one 
> case in 
> a select (what turns on all the heavy machinery of a full select block). 

I do agree. I really ever benchmarked the difference, the two-select-blocks 
only consumes about 5% more CPU. So, for this use case, the main benefit of
supporting priority-case-order select block is it makes code look less 

As for another use case shown in the first comment, 

    select {
    case <-done: return
    case queue <- data:

In fact, the code shown in that comment is not perfect, because in other 
the following two lines


might present a different order from they look in code. (I didn't find any 
official Go
documentation makes the guarantee that they will be closed by their 
appearance order in code.)

But if there is a way which can guarantee that "done" will always be closed 
before "queue"
(in the views of any goroutines), then

    select(ordered) {
    case <-done: return
    case queue <- data:

can be executed safely in multiple goroutines concurrently.
This will simplify the implementations for some situations.

Under the current select mechanism, without supporting priority-case-order 
select block,
programmers need to make more effort to implement the same situations.
(Maybe this is not bad, as programing with channels is really fun. ;D)


> Hope this helps, 
> -- 
> Wojciech S. Czarnecki 
>  << ^oo^ >> OHIR-RIPE 

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 

Reply via email to