Nonsense.
Closing channels is a generic means of broadcasting to all listeners a
state change.
To say that only one goroutine should ever initiate such a change is a
needless and pointless restriction.
On Tue, Dec 20, 2022 at 2:40 AM Jan Mercl <0xj...@gmail.com> wrote:
> On Tue, Dec 20, 2022
On Tue, Dec 20, 2022 at 9:21 AM Jason E. Aten wrote:
> Shutting down goroutines quickly was needed so often that I wrote a package
> to help me with it. it is called idem, short for idempotent.
>
> It uses the idea of an idempotent Close of a channel to signal that the
> goroutine should stop.
Shutting down goroutines quickly was needed so often that I wrote a package
to help me with it. it is called idem, short for idempotent.
It uses the idea of an idempotent Close of a channel to signal that the
goroutine should stop. This is because Go will panic if
close a channel more than once
It depends entirely on your application, and how the various goroutines are
wired together with channels.
But as a guiding principle: I'd say that anything which *sends* on a
channel should close it when it's finished - whether that be due to context
cancellation, or some other reason.
Hallöchen!
Brian Candler writes:
> On Monday, 19 December 2022 at 12:01:39 UTC Torsten Bronger wrote:
>
>> But would you agree that additional checking is necessary if
>> DoSomething does not have a ctx argument?
>
> Given that you're running DoSomething synchronously, it will always
> run to
On Monday, 19 December 2022 at 12:01:39 UTC Torsten Bronger wrote:
> But would you agree that additional checking is necessary if
> DoSomething does not have a ctx argument?
>
Given that you're running DoSomething synchronously, it will always run to
completion. So you'll always have a valid
Hallöchen!
Jan Mercl writes:
> [...]
>
> From https://go.dev/ref/spec#Select_statements
>
>
> 2. If one or more of the communications can proceed, a single one that
> can proceed is chosen via a uniform pseudo-random selection.
>
>
> Selecting the send case in the above code, when both
Hallöchen!
Harris, Andrew writes:
> The precise ordering of things is a bit non-deterministic at the
> fringe. If precise ordering really matters (maybe for cancelling a
> stream like this, it doesn’t, sometimes it does), a default case in
> the select statement is really useful, and it also
On Monday, 19 December 2022 at 10:01:41 UTC Torsten Bronger wrote:
> I would additionally check for ctx.Err() != nil somewhere in the
> loop. Or is there a reason why this is not necessary?
>
See https://pkg.go.dev/context#Context
// If Done is not yet closed, Err returns nil.
// If
