content: convert to Markdown-enabled present inputs

Converted blog to Markdown-enabled present (CL 222846)
using present2md (CL 222847).

For golang/go#33955.

Change-Id: Ib39fa1ddd9a46f9c7a62a2ca7b96e117635553e8
Reviewed-on: https://go-review.googlesource.com/c/blog/+/222848
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>

1 files changed, 17 insertions, 16 deletions

diff --git a/content/go-concurrency-patterns-timing-out-and.article b/content/go-concurrency-patterns-timing-out-and.article
index 0789006..09d2502 100644
--- a/content/go-concurrency-patterns-timing-out-and.article
+++ b/content/go-concurrency-patterns-timing-out-and.article
@@ -1,10 +1,11 @@
-Go Concurrency Patterns: Timing out, moving on
+# Go Concurrency Patterns: Timing out, moving on
 23 Sep 2010
 Tags: concurrency, technical
+Summary: Concurrent programming has its own idioms. A good example is timeouts. Although Go's channels do not support them directly, they are easy to implement. Say we want to receive from the channel `ch`, but want to wait at most one second for the value to arrive. We would start by creating a signalling channel and launching a goroutine that sleeps before sending on the channel:
 
 Andrew Gerrand
 
-* Introduction
+##
 
 Concurrent programming has its own idioms.
 A good example is timeouts. Although Go's channels do not support them directly,
@@ -14,22 +15,22 @@ but want to wait at most one second for the value to arrive.
 We would start by creating a signalling channel and launching a goroutine
 that sleeps before sending on the channel:
 
-	    timeout := make(chan bool, 1)
-	    go func() {
-	        time.Sleep(1 * time.Second)
-	        timeout <- true
-	    }()
+	timeout := make(chan bool, 1)
+	go func() {
+	    time.Sleep(1 * time.Second)
+	    timeout <- true
+	}()
 
 We can then use a `select` statement to receive from either `ch` or `timeout`.
 If nothing arrives on `ch` after one second,
 the timeout case is selected and the attempt to read from ch is abandoned.
 
-	    select {
-	    case <-ch:
-	        // a read from ch has occurred
-	    case <-timeout:
-	        // the read from ch has timed out
-	    }
+	select {
+	case <-ch:
+	    // a read from ch has occurred
+	case <-timeout:
+	    // the read from ch has timed out
+	}
 
 The `timeout` channel is buffered with space for 1 value,
 allowing the timeout goroutine to send to the channel and then exit.
@@ -39,7 +40,7 @@ before the timeout is reached.
 The `timeout` channel will eventually be deallocated by the garbage collector.
 
 (In this example we used `time.Sleep` to demonstrate the mechanics of goroutines and channels.
-In real programs you should use ` [[https://golang.org/pkg/time/#After][time.After]]`,
+In real programs you should use ` [time.After](https://golang.org/pkg/time/#After)`,
 a function that returns a channel and sends on that channel after the specified duration.)
 
 Let's look at another variation of this pattern.
@@ -71,10 +72,10 @@ in the loop will hang around.
 However, if the result arrives before the main function has made it to the receive,
 the send could fail since no one is ready.
 
-This problem is a textbook example of what is known as a [[https://en.wikipedia.org/wiki/Race_condition][race condition]],
+This problem is a textbook example of what is known as a [race condition](https://en.wikipedia.org/wiki/Race_condition),
 but the fix is trivial.
 We just make sure to buffer the channel `ch` (by adding the buffer length
-as the second argument to [[https://golang.org/pkg/builtin/#make][make]]),
+as the second argument to [make](https://golang.org/pkg/builtin/#make)),
 guaranteeing that the first send has a place to put the value.
 This ensures the send will always succeed,
 and the first value to arrive will be retrieved regardless of the order of execution.