When using a context.WithTimeout, I always felt that it should be the function where the context was created should be the one that ensures that it (the current function) does not block longer than intended. That is to say, it should call context.WithTimeout(), and then run the subsequent code in a goroutine (passing in the context most likely), whilst using a select multiplexer to listen to when the context is cancelled (by the timeout), and then resume. Here's an example of this https://go.dev/play/p/EGNlJqo3hY5
However, when I was looking at this on the go database docs, it seems to say to push that logic further down the stack to the 'child' (or callee) https://go.dev/doc/database/cancel-operations#:~:text=Canceling%20database%20operations%20after%20a%20timeout I think this is an alternative implementation of my first example, that is analogous to what the database package is suggesting https://go.dev/play/p/DABt-Z36T-F Whilst I understand that the child should listen for the signal and clean-up what it's doing in the event of the cancellation, that's doesn't feel like the same thing as the caller *relying* on that behaviour for the caller function to resume running. How should I think about this? Am I missing something here? -- 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/f45936f2-36b3-46cb-aa93-9bbbf9438843n%40googlegroups.com.
