Spread sequential tests into 4 go routines and terminate all if one fails

Suppose I have a simple loop which does sequential tests like this.

 for f := 1; f <= 1000; f++ {
    		if doTest(f) {
              break
            }
  }

I loop through range of numbers and do a test for each number. If test fails for one number, I break and exit the main thread. Simple enough.

Now, how do correctly feed the test numbers in say four or several go routines. Basically, I want to test the numbers from 1 to 1000 in batches of 4 (or whatever number of go routines is).
Do I create 4 routines reading from one channel and feed the numbers sequentially into this channel? Or do I make 4 routines with an individual channel?

And another question. How do I stop all 4 routines if one of them fails the test? I've been reading some texts on channels but I cannot put the pieces together.

You can create a producer/consumer system: https://play.golang.org/p/rks0gB3aDb

func main() {
	ch := make(chan int)
	clients := 4
	// make it buffered, so all clients can fail without hanging
	notifyCh := make(chan struct{}, clients)
	go produce(100, ch, notifyCh)

	var wg sync.WaitGroup
	wg.Add(clients)
	for i := 0; i < clients; i++ {
		go func() {
			consumer(ch, notifyCh)
			wg.Done()
		}()
	}
	wg.Wait()

}

func consumer(in chan int, notifyCh chan struct{}) {
	fmt.Printf("Start consumer\n")
	for i := range in {
		<-time.After(100 * time.Millisecond)
		if i == 42 {
			fmt.Printf("%d fails\n", i)
			notifyCh <- struct{}{}
			return
		} else {
			fmt.Printf("%d\n", i)
		}

	}
	fmt.Printf("Consumer stopped working\n")
}

func produce(N int, out chan int, notifyCh chan struct{}) {
	for i := 0; i < N; i++ {
		select {
		case out <- i:
		case <-notifyCh:
			close(out)
			return
		}
	}
	close(out)
}

The producer pushes numbers from 0 to 99 to the channel, the consumer consumes until the channel is closed. In main we create 4 clients and add them to a waitgroup to reliably check if every goroutine returned.
Every consumer can signal on the notifyCh, the producer stops working and no further numbers are generated, therefor all consumers return after their current number.

There's also an option to create 4 go routines, wait for all of them to return, start the next 4 go routines. But this adds quite an overhead on waiting.

Since you mentioned prime numbers, here's a really cool prime seive: https://golang.org/doc/play/sieve.go

Whether you will create one channel common or a channel per routines depend on what you want.

If you want only put some numbers (or more general - requests) inside and you don't care which goroutine serve that, than of course is better to share a channel. In case when you want for example first 250 request to be served by goroutine1, than of course you cannot share a channel.

For channel is a good practice use it as input or output. And the simples thing how sender can sent, that he is finished is close the channel. Good article about that is https://blog.golang.org/pipelines

What is not mentiond in the question - is you need also another channel (or channels) or or any other communication primitive to get results. And here is the channel most interesting than to feeding.

What information should be sent - it should be sent, a bool after every doTest, or just know when everthing was done (it this case neither bool is not necessary just close a channel)?

If you prefer program at first fail. Than I would prefer use buffered shared channel to feed the numbers. Don't forget to close it, when all numbers will be feed.

And another unbuffered chan to let main thread know, that tests are done. It can be channel, there you only put the number, where test failed, or if you also want a positive result - channel of struct containing number and result, or any other informantion returned from doTest.

Very good article about channel is also http://dave.cheney.net/2014/03/19/channel-axioms

Each of your four goroutines can report a failure (by sending error and closing channel). But gotcha is what goroutines should do, when all numbers passed and feeding channel is closed. And about that is also nice article http://nathanleclaire.com/blog/2014/02/15/how-to-wait-for-all-goroutines-to-finish-executing-before-continuing/