That one time I used Go panics for flow control
13 points by noncrab
13 points by noncrab
We have tried this solution but agreed on a separate goroutine for sorting (and a few other cpu intensive things).
As agwa points out, goroutines might be cheap, but the workload wasn't. We were mainly bounded by a combination of the number of cores available (as I mention it wasn't autoscaled) and the target latency for these requests.
We might have been able to do something with a bounded worker pool that could reject work pre-emptively when overloaded, but that would be more complex, be harder to understand and debug. And while the extra memory loads aren't going to help performance overall, we could scale it to suit.
Goroutines aren't cheap if they're executing a sorting algorithm! I don't think your solution addresses the problem in the blog post.
Is this worth it? Maybe there is a cost to having those panic handlers there and panicking, and maybe the costs outweigh the costs of sorting?
Reminder that http.Server uses panics for flow control (iirc something about aborting failed responses or so), which is important to know if you're writing panic-handling middleware