runtime: use exitGoroutine instead of deadlock

This makes the meaning more clear. And while the behavior is currently
the same, when we start to use threads we should actually exit the
goroutine when calling runtime.Goexit() instead of just leaving it
deadlocked.

Author: aykevl

src/runtime/panic.go

@@ -71,9 +71,9 @@ func panicOrGoexit(message interface{}, panicking panicState) {
 		}
 	}
 	if panicking == panicGoexit {
-		// Call to Goexit() instead of a panic.
+		// This is a call to Goexit() instead of a panic.
 		// Exit the goroutine instead of printing a panic message.
-		deadlock()
+		exitGoroutine()
 	}
 	printstring("panic: ")
 	printitf(message)

src/runtime/scheduler_cooperative.go

@@ -45,9 +45,18 @@ var (
 //
 //go:noinline
 func deadlock() {
-	// call yield without requesting a wakeup
+	exitGoroutine()
+}
+
+func exitGoroutine() {
+	// Pause the goroutine without a way for it to wake up.
+	// This makes the goroutine unreachable, and should eventually get it
+	// cleaned up by the GC.
 	task.Pause()
-	panic("unreachable")
+
+	// We will never return from task.Pause(). Make sure the compiler knows
+	// this.
+	trap()
 }
 
 // Add this task to the end of the run queue.

src/runtime/scheduler_none.go

@@ -36,6 +36,12 @@ func deadlock() {
 	runtimePanic("all goroutines are asleep - deadlock!")
 }
 
+func exitGoroutine() {
+	// There is only one goroutine, which would exit, so that leads to a
+	// deadlock.
+	deadlock()
+}
+
 func scheduleTask(t *task.Task) {
 	// Pause() will panic, so this should not be reachable.
 }