-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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: context: enable first class citizenship of third party implementations (case when custom context needs to create is own done channel) #36448
Comments
Note that it doesn't actually need to allocate its own Consider: https://play.golang.org/p/w-EniGk-qcH |
@bcmills, thanks for feedback. It is true that we can avoid third-party done channel and extra goroutine if only one of the parents is cancellable. However, as you say, in general case for For the reference: since |
P.S. another point in case where context merging might be useful is #30694. @taralx wrote in #30694 (comment) (emphasis mine):
|
I tend to agree. Want to file a separate proposal for that? |
Thanks. I filed it at #36503. |
Judging by #33502 this proposal seems to have been missed. Could someone please add it to |
golang/go#36503 golang/go#36448 They are there for 6 months already without being considered for real and so the progress is very unlikely, but still...
Now that we accepted and implemented #40221, is there anything left for this proposal? |
This proposal has been added to the active column of the proposals project |
No, thank you. |
. |
This proposal has been declined as retracted. |
Hello up there.
Please find below description of real-world case where third party context needs to create its own done channel. @rsc was asking for example of such cases and I already commented on the subject on #28728 (comment), but it looks that feedback was lost due to that #28728 was already closed. Please either reopen #28728 or consider my case here. Thank you.
---- 8< ----
@rsc wrote at #28728 (comment):
@rsc wrote at #28728 (comment):
I'm a bit late here, but below is example of real-world usage where custom context needs to create its own done channel: this need arises when one wants to merge two contexts to cancel the work when either the service is stopped, or when caller's context is canceled. Let me quote https://godoc.org/lab.nexedi.com/kirr/go123/xcontext#hdr-Merging_contexts to explain:
---- 8< ----
Merging contexts
Merge could be handy in situations where spawned job needs to be canceled whenever any of 2 contexts becomes done. This frequently arises with service methods that accept context as argument, and the service itself, on another control line, could be instructed to become non-operational. For example:
func Merge
Merge merges 2 contexts into 1.
The result context:
Canceling this context releases resources associated with it, so code should call cancel as soon as the operations running in this Context complete.
---- 8< ----
To do the merging of
ctx
andsrv.serveCtx
done channels current implementation has to allocate its own done channel and spawn corresponding goroutine:https://lab.nexedi.com/kirr/go123/blob/5667f43e/xcontext/xcontext.go#L90-118
https://lab.nexedi.com/kirr/go123/blob/5667f43e/xcontext/xcontext.go#L135-150
context.WithCancel
, when called on resulting merged context, will have to spawn its own propagation goroutine too.For the reference here is
context.Merge
implementation in Pygolang that does parents - child binding via just data:https://lab.nexedi.com/kirr/pygolang/blob/64765688/golang/context.cpp#L74-76
https://lab.nexedi.com/kirr/pygolang/blob/64765688/golang/context.cpp#L347-352
https://lab.nexedi.com/kirr/pygolang/blob/64765688/golang/context.cpp#L247-251
https://lab.nexedi.com/kirr/pygolang/blob/64765688/golang/context.cpp#L196-226
Appologize, once again, for being late here, and thanks beforehand for taking my example into account.
Kirill
/cc @Sajmani
The text was updated successfully, but these errors were encountered: