You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Another use of this package brought to mind a possible improvement: Checking whether the context is cancelled in Go().
This isn't something golang.org/x/sync does, but given this package's Go() can block, I wonder if it might be useful.
In my use case I am calling Go() thousands of times with a limited number of workers. I wondered what would happen if one of the goroutines returned with an error. Currently in my case they will do some non-context aware work before using the context and then they would see it is cancelled and return. So there would be a bunch of work done and likely Go() would be blocked, causing the error to not be seeing as quickly as it might be otherwise. Whereas if Go() checked the context and returned without invoking the callback, this would be less of a concern.
Essentially I'm thinking of making it as quick as possible to get to knowing there was an error.
I could check the context in my callback or make my code more context aware, but I suppose I'm thinking it might be a nice addition to this package. Although I wonder whether it'd need an additional Go() function that is context aware, unless we held on to the context when creating the errgroup.
I could probably come up with a PR if you think it'd be suitable.
Thanks for your time!
The text was updated successfully, but these errors were encountered:
Hi again!
Another use of this package brought to mind a possible improvement: Checking whether the context is cancelled in
Go()
.This isn't something
golang.org/x/sync
does, but given this package'sGo()
can block, I wonder if it might be useful.In my use case I am calling
Go()
thousands of times with a limited number of workers. I wondered what would happen if one of the goroutines returned with an error. Currently in my case they will do some non-context aware work before using the context and then they would see it is cancelled and return. So there would be a bunch of work done and likelyGo()
would be blocked, causing the error to not be seeing as quickly as it might be otherwise. Whereas ifGo()
checked the context and returned without invoking the callback, this would be less of a concern.Basically my use looks something like:
Essentially I'm thinking of making it as quick as possible to get to knowing there was an error.
I could check the context in my callback or make my code more context aware, but I suppose I'm thinking it might be a nice addition to this package. Although I wonder whether it'd need an additional
Go()
function that is context aware, unless we held on to the context when creating theerrgroup
.I could probably come up with a PR if you think it'd be suitable.
Thanks for your time!
The text was updated successfully, but these errors were encountered: