New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: sync: add blocking methods with Context parameter to Once and WaitGroup #25312
Comments
Use case: |
I don't see how this could work in general. If you call Perhaps something like this code would do what you want: c := make(chan bool, 1)
go func() {
once.Do(f)
c <- true
}()
select {
case <-c:
case <-ctxt.Done():
return
} Here it is clear that the context is being handled by this code, and doesn't really have anything to do with |
|
@ianlancetaylor, the code fragment you provided is my current workaround but implemented within sync.Once, an atomic checking can be done before the goroutine is started and the channel is made. |
Making channels and goroutines are cheap. My point is that for that use case the Context argument doesn't actually have anything to with the Once operation. We're very unlikely to add new API for this. If the efficiency really matters here, which I'm skeptical of, then I think a cleaner approach would be to add a If efficiency really matters here for you, I suggest that you simply copy and modify the |
I believe it'll be less than 50 lines because context is newly introduced (into Golang built-in lib) so I think majority of blocking methods should try to be context friendly, i.e. it returns when the caller's context is cancelled. When context is more and more widely used, this request is not a rare case for me. |
Context is very useful for cases where an operation can be canceled or time out. In your proposal the operation can not be canceled. |
In my case, the caller is in handling an operation that can be cancelled but may need lazily do an intialization op (which cannot be cancelled) once. |
Yes, exactly: the initialization operation can not be canceled. |
The initialization, once started, can't be cancelled, but if initialization were running in a different goroutine then waiting for the initialization could be cancelled. Same for waitgroup. So I guess it's possible, although DoWithContext is 6X longer than Do. |
This seems like it is useful only in limited circumstances. And sync.Once is not making any special use of APIs internal to the standard library. So it seems like the right thing to do is to just make a new package that is customized to your use. Feel free to start with sync.Once (respecting the license of course). |
I have a similar need as the OP. For future visitors to this issue, I've implemented my solution to this at https://github.com/virtuald/go-oncectx |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?1.10.2
Does this issue reproduce with the latest release?
n/a
What operating system and processor architecture are you using (
go env
)?all
What did you do?
n/a
What did you expect to see?
sync.Once once;
once.DoWithContext(ctx, f) // when ctx is cancelled, f is still running but the caller can return immediately
Similar to WaitGroup.WaitWithContext.
What did you see instead?
n/a
The text was updated successfully, but these errors were encountered: