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
version
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
verbose.
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
goroutines,
the following two lines
close(done)
close(queue)
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
https://groups.google.com/d/msgid/golang-nuts/192244b6-61d1-43c5-9b16-992a3d02f756%40googlegroups.com.
