internal/singleflight: delete, use golang.org/x/sync/singleflight

[bradfitz]

The singleflight package started life in internal/singleflight and then moved to golang.org/x/sync/singleflight, and the two have had slightly divergent development histories since. It's getting kinda messy. Their APIs have even somewhat diverged.

I just tried to re-unify them and delete internal/singleflight from std, but we can't use mod/vendor packages during bootstrap.

/cc @ianlancetaylor

[gopherbot]

Change https://golang.org/cl/174080 mentions this issue: src/vendor: add golang.org/x/sync/singleflight, delete internal/singleflight

[cuonglm]

Another step to re-unify them is:

• Adding a new method to golang.org/x/sync/singleflight to report something like this 6c877e5#diff-64cfc9b51215a4e84f98e7a67cfa800a

• Change golang.org/x/sync/singleflight to behave the same as internal/singleflight.

I vote for 1st point, 2nd point will break current user of golang.org/x/sync/singleflight out there. How do you think @bradfitz ?

[bradfitz]

We can't break (change) the x/sync/singleflight public API.

We can add a new method, though.

[tarndt]

If github.com/golang/sync another fork or is that just a clone of golang.org/x/sync? I've been unsure which should be imported.

[cuonglm]

@tarndt Use golang.org/x/sync, it's custom import path for github.com/golang/sync https://github.com/golang/sync/blob/master/singleflight/singleflight.go#L7

[gopherbot]

Change https://go.dev/cl/423654 mentions this issue: net: avoid relying on singleflight.Group.DoChan to detect hook called

[gopherbot]

Change https://go.dev/cl/423655 mentions this issue: internal/singleflight: make DoChan only return Result channel