Live data from Hacker News

Understanding Singleflight in Go

codingexplorations.com

11–12 of 12 posts

Re: Understanding Singleflight in Go

#11

> This pattern is particularly useful in scenarios where caching isn't suitable or when the results are expected to change frequently Any suitable examples? In the linked posts it gives querying weather service as an example but still uses a cache. Even with a normal concurrent request to a single function, a caching layer can be added before it makes any external request. Or am I misunderstanding this use case?

I think the idea is to avoid problems with functions or APIs that have side effects. You want to make sure you perform the task only once. Or you want to make sure you’re not burning money on some commercial API through redundant calls. It‘s not necessarily about performance, hence why the weather service example also uses an additional cache specifically for performance.

Re: Understanding Singleflight in Go

#12
The problem with singleflight is that when a goroutine that grabs it first happens to be a slow request, it slows down entire group. What's worse is if it returns error, rest of group share the fate. That sometimes shows in bursts of cancellations on one of goroutines timing out.

Better would be if it was semaphoreflight e.g. allow up to N concurrent requests to proceed to amortize this.

Another issue is there's per group lock that can generate meaningful contention just to check the result.

Post reply on HN