4 ms·
Thanks for this article. Do you find that incrementing the waitgroup on every accept tends to become a bottleneck? Or are you siloing your server on a single
by stuckagain 10y ago
Thanks for this article. Do you find that incrementing the waitgroup on every accept tends to become a bottleneck? Or are you siloing your server on a single core or something like that?
- gtrubetskoy 10y ago> Do you find that incrementing the waitgroup on every accept tends to become a bottleneck? The specific thing I was dealing with when I wrote the blog post wasn't high-volume enough for it to make any difference, so I don't really know.... But is there a better option than a WaitGroup here?
- politician 10y agoCheck out the Context API, it's a standardization of several cancellation approaches.
- deleted 10y ago[deleted]
- lclarkmichalek 10y agoAnd x/sync/errgroup if you want the lovechild of context and WaitGroup
- Matthias247 10y agoThose two go hand in hand. Even if you you context (or a bare channel) for signaling the cancellation you often want to wait until the cancellation really happened and the child task terminated. For this task WaitGroup is the easiest thing to use.
- Matthias247 10y agoIt should be negligible. It's an atomic add, and the OS accept function call should also be much more heavy weight. Add to that lots of synchronization that will happen on all further socket HTTP/socket reads/writes, especially if it's HTTP/2.