Marvin: That's pretty much the thinking behind the design. Thanks for the
clear explanation.
-rob
On Wed, Jan 24, 2018 at 5:31 AM, Marvin Renich <m...@renich.org> wrote:
> * 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.
>
--
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.
