4 ms·
What would you suggest as an alternative?
by bheadmaster 2y ago
What would you suggest as an alternative?
- orf 2y ago[flagged]
- bheadmaster 2y agoThank you for your helpful input.
- orf 2y agoNo worries, this help also generalises to any time you want to add locking/synchronisation or other overheads to a hot code path. It’s best not to acquire a mutex and launch a goroutine to read 3 bytes of data at a time. Also, hot tip: you can like… benchmark this. It’s not illegal.
- bheadmaster 2y ago> It’s best not to acquire a mutex and launch a goroutine to read 3 bytes of data at a time. io.Copy uses 32KB buffers. Other parts of standard library do too. If you're using Read() to read 3 bytes of data at a time, mutex is the least of your worries. Since you seem to be ignoring sarcasm of my previous comment - just saying "don't do that" without suggesting an alternative way in the particular code context you're referring to, isn't useful at all. It's just annoying.
- orf 2y agoIt may well use 32KB buffers, or any size, but that doesn’t translate to “reading 32KB at a time”. If you’re aborting specifically an io.Copy, then there are better ways to do that: abort in the write path rather than the read path. It’s not my job to provide you with alternative code. That’s your job.
- bheadmaster 2y ago> It’s not my job to provide you with alternative code. That’s your job. It is not your job to tell me "that is wrong", yet you do it because it's easy. Suggesting an alternative (not necessarily providing the code) is less easy, so you don't wanna do it. That's fine. I just want you to be aware that the former without the latter is pretty much useless.
- orf 2y agoIt is also easy to tell you that you’re wrong if you were to post that you use your forehead to hammer nails into a post. Posting detailed instructions on how to identify, purchase and utilise a hammer isn’t something I need to do, and doesn’t negate the correctness of the initial “don’t do that”.
- foldr 2y agoYou've been missing the point of bheadmaster's posts, which (as it seems to me) was to show that "you can compose context-aware code with context-oblivious code (by passing context.Background()), and vice versa with no problems". Bheadmaster gave some proof of concept code showing how to do that. The code might be somewhat inefficient, but that doesn't invalidate the point. If you think there's a more efficient way to compose context-aware code with context-oblivious code, then the best way to make that case would be to explain how to do so.