I was about to make a PR but saw in the tests that context is already being
used as a closure and since I've been both wrong and do not have a
convincing reasoning for this change, it seems things are working fine.
On Monday, February 27, 2017 at 5:59:55 PM UTC+3:30, dc0d wrote:
>
> According to
According to the docs "Wait blocks until all function calls from the Go
method have returned, then returns the first non-nil error (if any) from
them"; it doesn't say if I cancel the original context what will happen.
The parent/child pattern for using contexts (a hierarchy of contexts) is
not
On Mon, 27 Feb 2017, at 11:39 AM, dc0d wrote:
> Is there any drawbacks if we put the CancelFunc of a cancellable
> context.Context inside it's values?
>
> Problem: I needed a cross breed of WaitGroup and Context. So a
> WaitGroup and it's CancelFunc is put inside it's values and are used
> wit
Is there any drawbacks if we put the CancelFunc of a cancellable
context.Context inside it's values?
Problem: I needed a cross breed of WaitGroup and Context. So a WaitGroup
and it's CancelFunc is put inside it's values and are used with some helper
functions. I wrote a variant of WaitGroup - w
