From fe6ae451c13e64f33547fe4a029d8a748689f977 Mon Sep 17 00:00:00 2001 From: kenctrl Date: Tue, 11 Mar 2025 19:24:15 -0400 Subject: [PATCH] update --- src/kvraft1/test.go | 2 +- src/raft1/raft.go | 17 ++++++++--------- 2 files changed, 9 insertions(+), 10 deletions(-) diff --git a/src/kvraft1/test.go b/src/kvraft1/test.go index 3ef2787..2d7b80a 100644 --- a/src/kvraft1/test.go +++ b/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 } diff --git a/src/raft1/raft.go b/src/raft1/raft.go index fd35de5..d93487f 100644 --- a/src/raft1/raft.go +++ b/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., -// when it simulates a crash and restarts the peer or when the test is -// done). Kill allows your implementation (1) to close the applyCh so -// that the application on top of Raft can clean up, and (2) to return -// out of long-running goroutines. +// the tester doesn't halt goroutines created by Raft after each test, +// but it does call the Kill() method. your code can use killed() to +// check whether Kill() has been called. the use of atomic avoids the +// need for a lock. // -// Long-running goroutines use memory and may chew up CPU time, -// perhaps causing later tests to fail and generating confusing debug -// output. any goroutine with a long-running loop should call killed() -// to check whether it should stop. +// the issue is that long-running goroutines use memory and may chew +// up CPU time, perhaps causing later tests to fail and generating +// confusing debug output. any goroutine with a long-running loop +// should call killed() to check whether it should stop. func (rf *Raft) Kill() { atomic.StoreInt32(&rf.dead, 1) // Your code here, if desired.