On Wednesday, 12 January 2022 at 08:41:23 UTC lege...@gmail.com wrote: > What I think it's not so good is that I must add the select at all the > places the goroutine is waiting or looping >
I don't think you do. Well-behaved functions which take a Context will return with an error if the context is cancelled - and presumably you're already checking for an error, so it doesn't make any difference. If you're waiting for communication on a channel, then you *may* need to check for context. But if you're reading from a channel, and the context propagates to the other goroutine, and the other goroutine closes the channel, then that's not an issue either. When it becomes a bit awkward is with IO on sockets, since io.Reader/io.Writer don't have a context. There is a long discussion at #20280 <https://github.com/golang/go/issues/20280>, and I made some notes here <https://github.com/golang/go/issues/20280#issuecomment-655588450>. The pattern which was explained to me is that you can have a separate thread which waits for the context close, and then sets a read or write deadline on the IO; that will cause an ongoing operation to terminate immediately. I don't know if there's a DNS client library which implements this pattern. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/8a5179c8-8e98-4b77-9fce-d2fdfb8b371bn%40googlegroups.com.
