update

src/kvraft1/test.go

@@ -87,6 +87,6 @@ func (ts *Test) makeTitle() string {
 	} else {
 		title = title + "one client"
 	}
-	title = title + " (" + ts.part + ")" // 4A or 4B
+	title = title + " (" + ts.part + ")" // 4A, 4B, 4C
 	return title
 }

src/raft1/raft.go

@@ -174,16 +174,15 @@ func (rf *Raft) Start(command interface{}) (int, int, bool) {
 	return index, term, isLeader
 }
 
-// The tester calls Kill() when it is done with a Raft instance (e.g.,
+// the tester doesn't halt goroutines created by Raft after each test,
-// when it simulates a crash and restarts the peer or when the test is
+// but it does call the Kill() method. your code can use killed() to
-// done).  Kill allows your implementation (1) to close the applyCh so
+// check whether Kill() has been called. the use of atomic avoids the
-// that the application on top of Raft can clean up, and (2) to return
+// need for a lock.
-// out of long-running goroutines.
 //
-// Long-running goroutines use memory and may chew up CPU time,
+// the issue is that long-running goroutines use memory and may chew
-// perhaps causing later tests to fail and generating confusing debug
+// up CPU time, perhaps causing later tests to fail and generating
-// output. any goroutine with a long-running loop should call killed()
+// confusing debug output. any goroutine with a long-running loop
-// to check whether it should stop.
+// should call killed() to check whether it should stop.
 func (rf *Raft) Kill() {
 	atomic.StoreInt32(&rf.dead, 1)
 	// Your code here, if desired.