Hello John
Not sure how relevant for the topic, but: there exist a way to "try to
read a channel, in a non-blocking way if no value is ready yet", using
*default* :
select {
case x, ok := <-ch:
if ok {
fmt.Printf("Value %d was read.\n", x)
} else {
fmt.Println("Channel closed!")
}
default:
fmt.Println("No value ready, moving on.")
}
see
http://stackoverflow.com/questions/3398490/checking-if-a-channel-has-a-ready-to-read-value-using-go/14092860#14092860
I've never had to use this idiom and I would rather discourage it because
it's a code smell of possible busy loop.
Cheers
Val
On Friday, January 20, 2017 at 6:59:33 PM UTC+1, John C. wrote:
>
> Thank you for the explanations. I also received a helpful note off list,
> put here for posterity:
>
>
> --------------------------
>
> Correct! ;-)
> ---
>
> Aha, I have no way of finding out whether a channel is ready to proceed
>>> without actually proceeding or blocking.
>>>
>>> On xxxxx wrote:
>>>
>>>> On xxxxx wrote:
>>>>
>>>> > While I understand just fine how to use select/goroutines/channels,
>>>> the overarching importance of select as a built-in feature is escaping
>>>> me.
>>>>
>>>> I suggest a thought experiment. You understand just fine how to use the
>>>> select statement, so maybe try to imagine how are you'd code some
>>>> task, where you use normally use select, _without_ it. What'll be the
>>>> [most important] difference?
>>>> --
>>>>
>>>> -j
>>>>
>>>
--
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.
