The third option was the expected one. Locking aside (as the thought line
behind the original question), the time spent on preparing/calculating a
result value to be sent to a channel, is not directly relevant to the case
for nil channels - which were expected to get ignored. I do not understand
the internals of select statement and did not know it locks the channel.
Thanks for the reply.
On Tuesday, January 23, 2018 at 11:42:17 PM UTC+3:30, Rob 'Commander' Pike
wrote:
>
> 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 <mr...@renich.org
> <javascript:>> wrote:
>
>> * dc0d <kaveh.sh...@gmail.com <javascript:>> [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...@googlegroups.com <javascript:>.
>> 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.
