-
Notifications
You must be signed in to change notification settings - Fork 306
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
Add context
support to Go
method?
#107
Comments
We may also want to cancel the scope by using the contexts. |
Hi @molon! Thanks for the detailed request. The reason I initially avoided adding an API like this was because I thought it made it easier to use incorrectly by not calling Consider this toy example: p := pool.New().WithMaxGoroutines()
for i := 0; i < 10; i++ {
i := i
err := p.TryGo(ctx, func() {
doSomeLongTaskThatMightPanic(ctx)
})
if err != nil {
p.Wait() // This is really easy to forget
return err
}
}
p.Wait()
return nil In that example, failing to wait means the panic is never propagated and concurrency is not scoped because there are still background goroutines executing after return. Instead, the contract is "calling p.Go() guarantees the task will run to completion if p.Wait() is called." Since concurrency in go is all cooperative "completion" here might just mean "the task reads from the outer context and exits early." So if you care about exiting early, your tasks can respect a context and p := pool.New().WithMaxGoroutines()
for i := 0; i < 10; i++ {
if err := ctx.Err(); err != nil {
p.Wait()
return err
}
i := i
p.Go(func() {
doSomeLongTaskThatMightPanic(ctx)
})
}
p.Wait()
return nil This example achieves almost the same thing as So I guess where I'm at is I don't really see much additional value compared to just having cancellable tasks, and adding a cc @bobheadxi for thoughts as well |
Hi, @camdencheek I understand your point of view. But what I want is to be able to control the timeout of Also, I suspect that the way I'm using simulation scene
Now what I want to know is whether I am using And please noteThis is safe if the
|
This simulation example sounds to me like a long-lived pool, where multiple publishers/submitters push things into a shared pool/backlog/processing queue, where the publishers have requirements of their own: deadline to submit job, etc. and the This idea is a valid one, but one that currently does not fit into anything provided by The biggest pitfalls are:
Does this comparison sound right? |
Indeed like a long life pool. But maybe the execution process is defined by the publisher, not the subscriber. About pitfalls:
All in all, the key points that I personally care more about are:
|
conc/pool/pool.go
Lines 54 to 67 in 1d4991d
If
WithMaxGoroutines
is set, the caller may block until a worker is released, but in some scenarios, it is necessary for the caller to decide when to cancel or wait for a timeout.func (p *Pool) GoContext(ctx context.Context, f func()) error
or
func (p *Pool) TryGo(ctx context.Context, f func()) error
The text was updated successfully, but these errors were encountered: