Go channel : the function of one extra line

I am learning Concurrency Pattern in Go, not sure about what is the purpose for Point A ?

Code is taken from: https://talks.golang.org/2012/concurrency.slide#30

Can anyone explain to me ? Thanks

type Message struct {
	str  string
	wait chan bool
}

func main() {
	c := fanIn(boring("Joe"), boring("Ann"))
	for i := 0; i < 5; i++ {
		msg1 := <-c
		fmt.Println(msg1.str)
		msg2 := <-c
		fmt.Println(msg2.str)
		msg1.wait <- true
		msg2.wait <- true
	}
	fmt.Println("You're both boring; I'm leaving.")
}

func fanIn(input1, input2 <-chan Message) <-chan Message {
	c := make(chan Message)
	go func() {
		for {
			c <- <-input1
		}
	}()
	go func() {
		for {
			c <- <-input2
		}
	}()
	return c
}

func boring(msg string) <-chan Message { 
	waitForIt := make(chan bool)
	c := make(chan Message)
	go func() { // We launch the goroutine from inside the function.
		for i := 0; ; i++ {
			c <- Message{fmt.Sprintf("%s %d", msg, i), waitForIt}
			time.Sleep(time.Duration(rand.Intn(2e3)) * time.Millisecond)
			<-waitForIt                          // <-----------------Point A
		}
	}()
	return c // Return the channel to the caller.
}

fanIn spawns two goroutines reading from the first and second "boring" Message-channels. As either of both goroutine might be running (and the other one sleeping or running as well) we don't know the order in which the elements get written to the unifying channel:

A A A A A \
            > A B B A A A B A B B
B B B B B /

Note that the resulting sequence has no particular order.

This can be demonstrated by commenting out the "waiting"-channels:

Joe 0
Ann 0
Joe 1
Ann 1
Joe 2
Ann 2
Joe 3
Joe 4
Joe 5
Ann 3
You're both boring; I'm leaving.

The waiting channel exists to restore sequence as the slides you linked say. We want this:

A A A A A \
            > A B A B A B A B A B
B B B B B /

Note how Ann and Joe talk one after the other now:

Joe 0
Ann 0
Joe 1
Ann 1
Joe 2
Ann 2
Joe 3
Ann 3
Joe 4
Ann 4
You're both boring; I'm leaving.

The author of this piece of code decided to synchronize the writes to the channels by letting them wait on waitForIt and notifying in main. This behavior relies on the first two messages we get in main's for-loop to be in order. If they are not we'd get the inverse sequence.

Maybe I'm failing to see any more absolute synchronization guarantees, maybe the author didn't care about the order of the sequence as long as its a repeating sequence, but this code does not strike me as a particularly good example of concurrency and synchronization.

The whole presentation can be found on YouTube. Around 8 minutes it will get closer to your problem. Rob Pike explains everything, but (this is also what tomwilde said) the examples in presentation are shrinked to only let the audience see the most important stuff. Later on in the presentation, the "boring" will be replaced by "interesting". It will make it much more clear what Rob tries to explain.

Since the wait channel can contain only one element per time, PointA is just making sure that no one will go ahead by blocking the goroutine. He will then "unload" the channel in order, allowing the routine to continue