dispatcher.go

package main

import "fmt"

var WorkerQueue chan chan WorkRequest

func StartDispatcher(nworkers int) {
  // First, initialize the channel we are going to but the workers' work channels into.
  WorkerQueue = make(chan chan WorkRequest, nworkers)
  
  // Now, create all of our workers.
  for i := 0; i<nworkers; i++ {
    fmt.Println("Starting worker", i+1)
    worker := NewWorker(i+1, WorkerQueue)
    worker.Start()
  }
  
  go func() {
    for {
      select {
      case work := <-WorkQueue:
        fmt.Println("Received work requeust")
        go func() {
          worker := <-WorkerQueue
          
          fmt.Println("Dispatching work request")
          worker <- work
        }()
      }
    }
  }()
}

+1 line 8 s/but/put/

thanks for the great article. you mentioned The reason we send the work request to the worker in another goroutine, is so that we make sure the work queue never fills up.. Just to confirm, if downstream workers get bogged down, this cause an exorbitant amount of goroutines to be created. Could this result in OOM errors on the server? thanks @nesv

I have tried this example. What I have found out that if you stop your workers, then these goroutines

go func() {
          worker := <-WorkerQueue
          fmt.Println("Dispatching work request")
          worker <- work

will be blocked forever and abandonned, i.e. they just leak. If I do not stop the workers, I don't understand, how I can cancel the previous workRequests.