design/24543: make issues references into links
Change-Id: I2d6071b6fabbbb5ed4e4deea62fecf138228c0c2
Reviewed-on: https://go-review.googlesource.com/c/163797
Reviewed-by: Ian Lance Taylor <iant@golang.org>
diff --git a/design/24543-non-cooperative-preemption.md b/design/24543-non-cooperative-preemption.md
index 55f1842..888d296 100644
--- a/design/24543-non-cooperative-preemption.md
+++ b/design/24543-non-cooperative-preemption.md
@@ -65,7 +65,8 @@
This increases STW latency, and on large core counts can
significantly impact throughput (if, for example, most threads are
stopped while the runtime waits on a straggler for a long time).
- (#17831, #19241)
+ ([#17831](https://golang.org/issue/17831),
+ [#19241](https://golang.org/issue/19241))
2. This can delay scheduling, preventing competing goroutines from
executing in a timely manner.
@@ -81,7 +82,14 @@
This often indicates bad or buggy code, but is surprising
nonetheless and has clearly wasted a lot of developer time on
debugging.
- (#543, #12553, #13546, #14561, #15442, #17174, #20793, #21053)
+ ([#543](https://golang.org/issue/543),
+ [#12553](https://golang.org/issue/12553),
+ [#13546](https://golang.org/issue/13546),
+ [#14561](https://golang.org/issue/14561),
+ [#15442](https://golang.org/issue/15442),
+ [#17174](https://golang.org/issue/17174),
+ [#20793](https://golang.org/issue/20793),
+ [#21053](https://golang.org/issue/21053))
These problems impede developer productivity and production efficiency
and expose Go's users to implementation details they shouldn't have to
@@ -90,7 +98,8 @@
### Cooperative loop preemption
@dr2chase put significant effort into trying to solve these problems
-using cooperative *loop preemption* (#10958).
+using cooperative *loop preemption*
+([#10958](https://golang.org/issue/10958)).
This is a standard approach for runtimes employing cooperative
preemption in which the compiler inserts preemption checks and
safe-points at back-edges in the flow graph.
@@ -361,7 +370,7 @@
Perhaps more troubling is that some of the Windows syscall package
types have uintptr fields that are actually pointers, hence forcing
callers to perform unsafe pointer conversions.
-For example, see issue [#21376](golang.org/issue/21376).
+For example, see issue [#21376](https://golang.org/issue/21376).
### Ensuring progress with unsafe-points
diff --git a/design/24543/safe-points-everywhere.md b/design/24543/safe-points-everywhere.md
index ad9053f..329baf3 100644
--- a/design/24543/safe-points-everywhere.md
+++ b/design/24543/safe-points-everywhere.md
@@ -41,7 +41,7 @@
To @minux's credit, he suggested this in [the very first
reply](https://github.com/golang/go/issues/10958#issuecomment-105678822)
-to #10958.
+to [#10958](https://golang.org/issue/10958).
At the time we thought adding safe-points everywhere would be too
difficult and that the overhead of explicit loop preemption would be
lower than it turned out to be.
@@ -116,7 +116,7 @@
handling.
Having safe-points everywhere could simplify this.
-2. Debugger function calls (#21678).
+2. Debugger function calls ([#21678](https://golang.org/issue/21678)).
Currently it's essentially impossible for a debugger to dynamically
invoke a Go function call because of poor interactions with stack
scanning and the garbage collector.
