a <- <- b
è lo stesso a<- (<-b)
, perché i <-
associa operatore con la sinistra chan
possibile.
Quindi il select
ha un case
con un'operazione di invio (nel formato a<- (something)
). E quello che succede qui è che l'espressione sul lato destro dell'istruzione send (il valore da inviare) viene valutata per prima - che è <-b
. Ma questo bloccherà per sempre (perché nessuno sta trasmettendo nulla sul b
), quindi: formare
fatal error: all goroutines are asleep - deadlock!
relativa sezione del Spec: Select statements:
Execution of a "select" statement proceeds in several steps:
For all the cases in the statement, the channel operands of receive operations and the channel and right-hand-side expressions of send statements are evaluated exactly once, in source order, upon entering the "select" statement. The result is a set of channels to receive from or send to, and the corresponding values to send. Any side effects in that evaluation will occur irrespective of which (if any) communication operation is selected to proceed. Expressions on the left-hand side of a RecvStmt with a short variable declaration or assignment are not yet evaluated.
If one or more of the communications can proceed, a single one that can proceed is chosen via a uniform pseudo-random selection. Otherwise, if there is a default case, that case is chosen. If there is no default case, the "select" statement blocks until at least one of the communications can proceed.
...
Quindi, se default
è presente, il select
impedisce il blocco se nessuno delle comunicazioni può procedere in passaggio 2, ma il codice si blocca in passaggio 1.
solo per essere completa, se ci sarebbe un goroutine che avrebbe mandato un valore su b
, allora la valutazione di <- b
non bloccare, quindi l'esecuzione di select
non avrebbero bloccato nel punto 2, e si vedrebbe l'atteso "select worked as naively expected"
(perché ricevendo da a
potrebbe ancora non procedere quindi default
sarebbero scelti):
go func() { b <- 1 }()
select {
// ...
}
Prova sul Go Playground.