In a select statement, the buffer in channel will be used firstly or the pending queue value will be used firstly?

Recently I've been reading the source code of select in Go. There is some part of the code that I don't understand.

For example, when the channel being selected has a pending send operation, or a pending receive operation, it first uses the value from pending send instead of the value in channel buffer.

// pass 1 - look for something already waiting
	var dfli int
	var dfl *scase
	var casi int
	var cas *scase
	var recvOK bool
	for i := 0; i < ncases; i++ {
		casi = int(pollorder[i])
		cas = &scases[casi]
		c = cas.c

		switch cas.kind {
		case caseNil:
			continue

		case caseRecv:
			sg = c.sendq.dequeue()
			if sg != nil {
				goto recv
			}
			if c.qcount > 0 {
				goto bufrecv
			}
			if c.closed != 0 {
				goto rclose
			}

		case caseSend:
			if raceenabled {
				racereadpc(c.raceaddr(), cas.pc, chansendpc)
			}
			if c.closed != 0 {
				goto sclose
			}
			sg = c.recvq.dequeue()
			if sg != nil {
				goto send
			}
			if c.qcount < c.dataqsiz {
				goto bufsend
			}

		case caseDefault:
			dfli = casi
			dfl = cas
		}
	}

So I wrote some simple code to verify my assumption. But the result implies I'm wrong.

package main

import (
	"fmt"
	"time"
)

func main() {
	var mark chan int
	length := 3
	c := make(chan int, length)
	for i := 1; i <= length; i++ {
		c <- i
	}

	go func() {
		c <- 4
	}()

	time.Sleep(time.Millisecond * 10)
	select {
	case val := <-c:
		fmt.Println("receive val is ", val)
	case _ = <-mark:
		fmt.Println("block chan")
	}
}

The result is receive val is 1. However, I think the printed output should be receive val is 4. It seems that the select first uses value in buffer.

You read the source code wrong.

The code goto recv goes to a code block labelled recv, which is:

recv:
	// can receive from sleeping sender (sg)
	recv(c, sg, cas.elem, func() { selunlock(scases, lockorder) }, 2)
	if debugSelect {
		print("syncrecv: cas0=", cas0, " c=", c, "\n")
	}
	recvOK = true
	goto retc

And if you look in recv function (https://golang.org/src/runtime/chan.go#L607), which is defined in channel.go, you would see it read from the buffer if there is one. From the document of that function:

// recv processes a receive operation on a full channel c.
// There are 2 parts:
// 1) The value sent by the sender sg is put into the channel
//    and the sender is woken up to go on its merry way.
// 2) The value received by the receiver (the current G) is
//    written to ep.
// For synchronous channels, both values are the same.
// For asynchronous channels, the receiver gets its data from
// the channel buffer and the sender's data is put in the
// channel buffer.
// Channel c must be full and locked. recv unlocks c with unlockf.
// sg must already be dequeued from c.
// A non-nil ep must point to the heap or the caller's stack.

To conclude it, the case in question is just to see if there is a sender waiting on it, which means either due to the channel is unbufferred or the buffer of the channel is full; and it has nothing to do what value the receiver is receiving.

Your mark channel is not initialized [1], so it will never be ready, therefore never chosen in the select statement. Otherwise, when multiple cases are available at the same time, the select statement chooses one of them at random.

Furthermore you don't even send anything on mark, but if you attempted that, the send operation would block, as there can't be any receiver for a nil channel anyway.

If no case is ready, and there is a default case, the default is selected, otherwise it blocks.

Please check also the tour of Go.

<hr>

[1] a var declaration will leave mark to its zero value, which is nil.