We may also consider suitably annoying warnings if, for instance, listening on a public IP address without TLS enabled.
While I wholeheartedly agree with the concept, I would like to point...
Well, after some deliberation I figured it's probably best to not try to be too clever about it. How does this version look to you?
For full disclosure: the go analysis tool does indeed detect this as lostcancel, even though the description there explicitly...
It was only used by means of defer cancel(). This is already happening for the parent process. And as per the docs:
When a Context is canceled,...
Oh boy, the entire time I read withTimeout as withCancel (mostly because it also returns a cancel function pointer) 🤯
So in my attempt to switch the two lines, I actually subjected...
Got it, thanks for taking the time to help me understand it! It feels a bit like cheating to my inner C programmer, but the reasoning is sound! 😉
Looking forward to testing this!
Ah, right, sorry. I kind of saw that, but didn't quite grok the approach 🙂 How does that fare in terms of cleaning up resources? Won't a channel with pending messages then linger forever on the...
@emersion Sorry for only writing this now, I was out on vacation. But: I don't think this is sound? Seems susceptible to TOCTTOU: the bool may be atomic, but since different goroutines can run in different threads, it is possible that the value is true when checked in goroutine X, then another goroutine Y closes the channel, then X continues, and if I understand this issue correctly, a select on a closed channel will panic? I am not a go expert, so I don't know if there any guarantees that the runtime provides that prevent this, but from a pure concurrency theory PoV, I think this is an issue? Or maybe the select behavior changed?