title: Using a GoLang Routine to Return to Multiple Threads
body: <p>I am building an API that can queue up requests to GET an external website and subsequently perform some work by interacting with that API.  I am trying to figure out how to avoid duplicate
  simultaneous go routines.</p>
  <p>That is, assume a request comes in for <a href="http://www.example.com" rel="nofollow noreferrer">http://www.example.com</a>  The routine is launched to handle that URL which could last minutes or even hours.  Any number of other requests can come in while this is happening.  If the new requests are not already being worked on, they should proceed with their own routine to fulfill.</p>
  <p>However, if another request for example.com comes in, I want the thread that request comes in on to block until the previous example.com request is complete and then it may proceed (duplication is fine, if the first task succeeded it will be a quick GET to confirm, if it failed, trying again is fine).</p>
  <p>All of the code examples I've found use channels or waitgroups but these concepts all appear to only block one thread.  That is, the first example.com thread is waiting on say a channel to return a value, but I can't have example.com request #2 wait on that same channel since the result can only be read from the channel once.</p>
  <p>If it makes any difference, I am building a worker pool with 5 workers, and a worker won't be allocated if another worker is already working the example.com request.</p>
  <p>I've also considered using a buffer to keep track of the URLs that are currently being worked by the workers, but I wasn't sure how to block on waiting for the URL to be deleted from the buffer.  I saw an example using an infinite for loop and a break for when the URL is no longer in the buffer, but that seems like unnecessary CPU abuse (indefinitely doing a for range on the buffer looking for the URL to no longer be present and to then break).</p>
  <p>How do I queue these requests up?</p>
  <p>Edit: Solution I was looking for is signal channels.  Thanks to Burak Serdar for pointing me to it.  If anyone else needs this, Google &quot;signal channels&quot; and you'll find plenty of info.</p>