Question about x/sync/singleflight redundant go panic(e) in doCall method

jianghushinian · October 5, 2025, 8:04pm

Hi,

I have a question regarding the following code in the singleflight package:

singleflight/singleflight.go

v0.17.0


      
          			if len(c.chans) > 0 {
          				go panic(e)
          				select {} // Keep this goroutine around so that it will appear in the crash dump.
          			} else {

if len(c.chans) > 0 { go panic(e) select {} // Keep this goroutine around so that it will appear in the crash dump. }

It appears that the code uses go panic(e) inside a goroutine to trigger a panic in a separate goroutine. My question is whether this go panic(e) is really necessary, as it seems redundant.

github.com/golang/sync

singleflight/singleflight.go

v0.17.0


      
          		c.dups++
          		c.chans = append(c.chans, ch)
          		g.mu.Unlock()
          		return ch
          	}
          	c := &call{chans: []chan<- Result{ch}}
          	c.wg.Add(1)
          	g.m[key] = c
          	g.mu.Unlock()
          
          	go g.doCall(c, key, fn)
          
          	return ch
          }
          
          // doCall handles the single call for a key.
          func (g *Group) doCall(c *call, key string, fn func() (interface{}, error)) {
          	normalReturn := false
          	recovered := false
          
          	// use double-defer to distinguish panic from runtime.Goexit,

Here’s why: In the DoChan method, the call to g.doCall(c, key, fn) is already executed inside a new goroutine, so any panic inside doCall will already happen in that goroutine. The caller of DoChan will not be able to recover from the panic, as it’s happening in a separate goroutine. Therefore, triggering go panic(e) or panic(e) doesn’t really change the outcome, and the program will eventually crash either way.

Could you clarify if go panic(e) is a defensive programming practice or if it’s an unnecessary redundancy? From my understanding, it doesn’t provide additional value in terms of preventing a crash or recovering from a panic.

Thank you!

falco467 · October 10, 2025, 3:09pm

As the comment states this is a workaround. They want to crash the program, but also want to see the current routine in the crash-dump as an active routine. If you panic() from a routine that routine will stop running and depending on the panic being re-panic-ed the call-stack will also be lost. This can make it very hard to reason about the program state when the panic occured.

This workaround will preserve the original go-routine in its original state to help finding a possible error. But this comes at the cost of not being able to recover from this panic, since it is thrown in a new go routine which will immediately lead to program termination.

jianghushinian · November 14, 2025, 7:31am

The code go g.doCall(c, key, fn)has already started a new goroutine, which 100% guarantees that a panic triggered inside g.doCall’s internal code cannot be recovered by user-level recover. However, internally it again uses go panic(e). Clearly, this gois redundant?