github.com/varialus/godfly@v0.0.0-20130904042352-1934f9f095ab/doc/articles/concurrency_patterns.html (about)

     1  <!--{
     2  "Title": "Go Concurrency Patterns: Timing out, moving on",
     3  "Template": true
     4  }-->
     5  
     6  <p>
     7  Concurrent programming has its own idioms. A good example is timeouts. Although
     8  Go's channels do not support them directly, they are easy to implement. Say we
     9  want to receive from the channel <code>ch</code>, but want to wait at most one
    10  second for the value to arrive. We would start by creating a signalling channel
    11  and launching a goroutine that sleeps before sending on the channel:
    12  </p>
    13  
    14  {{code "/doc/progs/timeout1.go" `/timeout :=/` `/STOP/`}}
    15  
    16  <p>
    17  We can then use a <code>select</code> statement to receive from either
    18  <code>ch</code> or <code>timeout</code>. If nothing arrives on <code>ch</code>
    19  after one second, the timeout case is selected and the attempt to read from
    20  <code>ch</code> is abandoned.
    21  </p>
    22  
    23  {{code "/doc/progs/timeout1.go" `/select {/` `/STOP/`}}
    24  
    25  <p>
    26  The <code>timeout</code> channel is buffered with space for 1 value, allowing
    27  the timeout goroutine to send to the channel and then exit. The goroutine
    28  doesn't know (or care) whether the value is received. This means the goroutine
    29  won't hang around forever if the <code>ch</code> receive happens before the
    30  timeout is reached. The <code>timeout</code> channel will eventually be
    31  deallocated by the garbage collector.
    32  </p>
    33  
    34  <p>
    35  (In this example we used <code>time.Sleep</code> to demonstrate the mechanics
    36  of goroutines and channels. In real programs you should use <code>
    37  <a href="/pkg/time/#After">time.After</a></code>, a function that returns
    38  a channel and sends on that channel after the specified duration.)
    39  </p>
    40  
    41  <p>
    42  Let's look at another variation of this pattern. In this example we have a
    43  program that reads from multiple replicated databases simultaneously. The
    44  program needs only one of the answers, and it should accept the answer that
    45  arrives first.
    46  </p>
    47  
    48  <p>
    49  The function <code>Query</code> takes a slice of database connections and a
    50  <code>query</code> string. It queries each of the databases in parallel and
    51  returns the first response it receives:
    52  </p>
    53  
    54  {{code "/doc/progs/timeout2.go" `/func Query/` `/STOP/`}}
    55  
    56  <p>
    57  In this example, the closure does a non-blocking send, which it achieves by
    58  using the send operation in <code>select</code> statement with a
    59  <code>default</code> case. If the send cannot go through immediately the
    60  default case will be selected. Making the send non-blocking guarantees that
    61  none of the goroutines launched in the loop will hang around. However, if the
    62  result arrives before the main function has made it to the receive, the send
    63  could fail since no one is ready.
    64  </p>
    65  
    66  <p>
    67  This problem is a textbook example of what is known as a
    68  <a href="https://en.wikipedia.org/wiki/Race_condition">race condition</a>, but
    69  the fix is trivial. We just make sure to buffer the channel <code>ch</code> (by
    70  adding the buffer length as the second argument to <a href="/pkg/builtin/#make">make</a>),
    71  guaranteeing that the first send has a place to put the value. This ensures the
    72  send will always succeed, and the first value to arrive will be retrieved
    73  regardless of the order of execution.
    74  </p>
    75  
    76  <p>
    77  These two examples demonstrate the simplicity with which Go can express complex
    78  interactions between goroutines.
    79  </p>