Nothing is known beforehand indeed. That does not mean it's not possible to
expect a certain semantic for a certain syntax beforehand.
On Sunday, December 31, 2017 at 9:36:37 PM UTC+3:30, leaf...@gmail.com
wrote:
>
> > How putting one channel inside the parameters has not any effect on the
> lo
> How putting one channel inside the parameters has not any effect on the logic
> of that select statement.
True.
My point is, whether a channel is nil or not is often not known to the coder,
and this whether the first will be called or not is unknown. Pass the channel
as a parameter emphasize
I do not understand how that makes a difference. I expect a certain
behavior (whatever it is) to rely on. The pattern of using multiple
channels inside a goroutine loop is not something unknown in Go world. And
each case may change the value of other channels.
How putting one channel inside the
The point is, you will not know whether the caller send a nil or not.
dc0d於 2018年1月1日星期一 UTC+8上午1時27分29秒寫道：
>
> I do not see how it should make me panic. If it's nil, it will be ignored
> and if it's not nil only then calling first() should cause a dead lock.
> That's common sense.
>
> But since
I do not see how it should make me panic. If it's nil, it will be ignored
and if it's not nil only then calling first() should cause a dead lock.
That's common sense.
But since "it is working according to the spec", it seems I should live
with this and move on.
On Sunday, December 31, 2017 at
dc0d於 2017年12月31日星期日 UTC+8下午11時40分44秒寫道：
>
> Or the (not only) other option is check for nil channels before entering
> the scope of select?
>
Change a little bit of your code.
package main
import (
"log"
"time"
)
func main() {
f(nil)
f(make(chan bool))
}
func first() bool {
select
It would be much more odd, imho, for a select case to be chosen because a send
can proceed, and for it then to block while generating the value to send.
Simple politeness mandates that we have a value ready and evaluated when it
becomes time to send it.
//jb
On 31 Dec 2017, at 16:41, dc0d
mai
On Sun, Dec 31, 2017 at 4:41 PM dc0d wrote:
> Or the (not only) other option is check for nil channels before entering
the scope of select?
That would remove an equally important property that the RHS can se the
channel to nil.
tl;dr: The current design was thoroughly thought out. It's not perf
Or the (not only) other option is check for nil channels before entering
the scope of select?
--
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+unsubsc
On Sun, Dec 31, 2017 at 2:47 PM dc0d wrote:
> What is the expected output?
Deadlock, ofc. What else one could expect if the goroutine trying to
perform the initial phase the select statement is blocked forever and no
other userland goroutine executes?
The only other option would be for the sele
A more complete code:
package main
import (
"log"
"time"
)
func main() {
f()
}
func first() bool {
select {}
}
func f() {
// for demonstration purpose
var rcvd chan bool = nil
select {
case rcvd <- first():
case <-time.After(time.Second):
log.Println("timeout")
}
log.Println("d
dc0d於 2017年12月31日星期日 UTC+8下午8時21分29秒寫道：
>
> Consider this:
>
> func first() bool {
> select {}
> }
>
>
> And inside another function/goroutine:
>
> func f() {
> var rcvd chan bool
> select {
> case rcvd <- first():
> }
> }
>
> While rcvd is nil, this select statement (inside f) will block, f
Consider this:
func first() bool {
select {}
}
And inside another function/goroutine:
func f() {
var rcvd chan bool
select {
case rcvd <- first():
}
}
While rcvd is nil, this select statement (inside f) will block, forever.
IMHO that's unexpected.
--
You received this message because y
This has almost nothing to do with case statements or switches. Switch cases
are expressions, expressions have a defined evaluation process. That process
includes short circuiting boolean logic. Channel sends on the other hand have
no such short circuiting, whether used in a select case or not.
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 n
15 matches
Mail list logo
