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 completion. So you'll always have a valid data value to send.
>
> Do you want to throw this value away if the context was cancelled in
> the mean time? You can do this:
>
> select {
> case <-ctx.Done():
> return ctx.Err()
> default:
> select {
> case <-ctx.Done():
> return ctx.Err()
> case out <- v:
> }
> }
Yes, this is what I had in mind. (Or something very similar;
instead of the first “case”, an extra check of ctx.Err() at top
level.)
> [...]
>
> TBH, I don't like the idea of a function sending or not sending a
> message on a channel randomly (depending on whether the context
> was cancelled); it's a recipe for deadlocks IMO. You should
> consider either closing the 'out' channel, or sending a
> termination message down it, to signal that there's no more data.
> I would use *that* as the trigger to terminate the receiver,
> rather than the context cancellation.
I have an error channel that unblocks the receiver (and stops it
from expecting more data).
But here I am worried about terminating the *sender* timely. Does
cancellation mean that I should end the current loop whatever it
takes or that I should end ASAP?
Regards,
Torsten.
--
Torsten Bronger
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/87ili79z88.fsf%40physik.rwth-aachen.de.
