On Wed, Sep 20, 2023 at 7:47 AM Jerry Londergaard <jlonderga...@gmail.com> wrote: > > 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?
Both patterns have their uses. If the new goroutine can periodically check context cancellation and needs to do some cleanup, then it is best to pass the context down, clean up, and return on cancellation. If the new goroutine cannot check context cancellation, then the goroutine starting that new goroutine can deal with cancellation like you did, hoping that the new goroutine eventually ends. I usually use the former, but the latter has its uses if you are calling a third-party library or some operation you cannot cancel. If that operation never ends, the goroutine leaks. > > -- > 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. -- 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/CAMV2Rqr%2BsMQk8ho5gJToqoY%3DnqdDpFUt5t_S8cZzhgDHLJTNSQ%40mail.gmail.com.