* dc0d <kaveh.shahbaz...@gmail.com> [180123 08:45]:
> Can anybody help me understand the reason? (It's in the spec. That's not
> the reason)
>
> On Sunday, December 31, 2017 at 10:14:31 AM UTC+3:30, dc0d wrote:
> >
> > Assume there is this select statement:
> >
> > for {
> > select {
> > // ...
> > // ...
> >
> > case rcvd <- first():
> > }
> > }
> >
> >
> > The rcvd channel will be set to nil or a chan value, by it's own case or
> > other cases.
> >
> > If the rcvd channel is nil, that case should have no effect. But even
> > when rcvd channel is nil, the first() function will be called.
> >
> > I did not expect that. Why is that so?
There are several candidate designs for this. Here is my analysis of
the choices that I think are most worthy of consideration:
1. (The current spec) Evaluate all channel operands (send and receive)
and all expressions for values to be sent. Choose one of the
communication operations that is ready to proceed and do it.
2. Evaluate all channel operands. For all non-nil send channels,
evaluate all expressions for values to be sent. Choose one of the
communication operations that is ready to proceed and do it.
3. Evaluate all channel operands. Choose one of the communication
operations that is ready to proceed. If it is a send operation, now
evaluate its value expression. Perform the operation.
It is unclear to me whether you were expecting (2) or (3), but I don't
like either of these.
I do not like (2) because it is not determinable until execution of the
select statement which expressions for send operations will be executed.
Some values that will not be sent may be evaluated even though they will
not be used, while others might not be evaluated. This can vary from
one execution of the select statement to another within the same
invocation of the program.
I do not like (3) because, in order to ensure that the communication
operation that was chosen is still ready to proceed after evaluating its
value to be sent, the channel must be locked during evaluation of the
value, blocking other go routines that try to use the channel. This
might take any amount of time (e.g. tens of minutes, or even hours).
This goes completely against the design principles and goals of
channels.
Thus (1) is the clear winner. Did I miss the design that you were
expecting?
...Marvin
--
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.
For more options, visit https://groups.google.com/d/optout.
