If the channel is nil, there's nothing to lock. But also, there's no
sending happening.
But the conceptual locking Ian mentions is there no matter whether you a)
first compute the value and then wait to be able to send, or b) first wait
to be able to send and then compute the value. In both cases, you need to
lock the channel between deciding you can send and actually sending,
because otherwise, someone else might decide they can send too.
The difference is, that in a) this time-frame is much shorter than in b).
Also, FTR, I still believe it is unnecessarily complicated to talk about
select - exactly the same problems and things have to happen in a regular
send - if nothing else, then because you'll always want
ch <- expr
to behave the same way as
select {
case ch <- expr:
}
Talking about a normal send is conceptually simpler but the conclusions are
transferable between the two.
On Wed, Jan 24, 2018 at 5:03 PM, dc0d <kaveh.shahbaz...@gmail.com> wrote:
> Is this applied when the channel is nil? Does select statement first lock
> the channel then check if it's nil?
>
> On Wednesday, January 24, 2018 at 6:07:50 PM UTC+3:30, Ian Lance Taylor
> wrote:
>>
>> On Tue, Jan 23, 2018 at 10:13 PM, dc0d <kaveh.sh...@gmail.com> wrote:
>> >
>> > 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.
>>
>> Regardless of internal details, conceptually it has to lock the
>> channel. The select statement has to atomically 1) decide that the
>> channel has room for a new value; 2) send the new value to the
>> channel. There could be many goroutines sending to the channel
>> simultaneously. If the select statement picks the channel first and
>> then computes the value to send, then it has to ensure that no other
>> goroutine can send to the channel while computing the value, as
>> otherwise once it has the value it might not be able to send it.
>>
>> Ian
>>
> --
> 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.
