Yea looks a bit easier đź‘Ť
Kind regards
Reinhard
--
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.
For more options, vis
It’s channels either way: https://play.golang.org/p/OTNPsxiDSOp
A difference is no access to context.Context.Err(), but in this example the
error isn’t checked. My opinion is there’s no reason to bring in the whole
context when all that’s needed is a cancel action. Also there’s an added
compile
Not Tested sofar by myself but https://github.com/dc0d/goroutines seems to
hide all the complexity in a nice streamlined API.
Am Montag, 19. März 2018 08:46:07 UTC+1 schrieb Sathish VJ:
>
> Looks like this last one works but also quite complicated.
>
> One question ... what is the effect of hav
Well,
without the NOP (empty) default case the loop of the working routine gets
blocked by reading from the cancelation channel.
So whenever you want to get a non blocking channel operation wether read or
write remember the select with an empty default ;)
kind regards
Reinhard
Am Montag, 19.
Because then you have to deal with all the chennels by yourself. Using the
Context API looks for me a bit cleaner and even easier.
Am Montag, 19. März 2018 15:04:17 UTC+1 schrieb matthe...@gmail.com:
>
> Only a detail, but why not this instead as the API?
>
> func LongRunningTask(cancel <-chan st
Only a detail, but why not this instead as the API?
func LongRunningTask(cancel <-chan struct{}, index int) (err error) {
Matt
On Monday, March 19, 2018 at 7:43:19 AM UTC-5, rog wrote:
>
> Why not something more like this? https://play.golang.org/p/3t4UtoFkoIt
>
> A lot of this comes down to wh
Why not something more like this? https://play.golang.org/p/3t4UtoFkoIt
A lot of this comes down to what that long running task is doing.
If it's hard at work doing computational work, the polling approach
might be appropriate.
If it's mostly waiting on external events then passing the context
ins
Looks like this last one works but also quite complicated.
One question ... what is the effect of having "default" on line 24 as empty?
On 18 March 2018 at 14:21, 'Reinhard Luediger' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> I came to the following solution for my long running ta
to be clear, nobody's "reputation" is impugned here--i mean, not really.
this is about logic and engineering and sharing knowledge. asking about
edge conditions and what happens when rules are violated is all fair game.
sorry if i sounded too strong.
the crux of the "safe race" idea is most comput
>
> Only if it doesn't leave the shop like that, but with a P>0, it will.
Before commit I usually go through many iterations, but what I shared was
iteration one. I’m confident that iteration two wouldn’t have the data race
in my case.
I don’t think these playgrounds are a good place to find
Only if it doesn't leave the shop like that, but with a P>0, it will.
On Sat, 2018-03-17 at 15:24 -0700, matthewju...@gmail.com wrote:
> Defending my reputation, I’m here for people making things, not for
> beingÂ
> an educator. Thinking quickly and making it work even with mistakes
> can beÂ
> a
Defending my reputation, I’m here for people making things, not for being
an educator. Thinking quickly and making it work even with mistakes can be
a valid approach sometimes.
Matt
On Saturday, March 17, 2018 at 2:05:55 PM UTC-5, Michael Jones wrote:
>
> these are excellent answers.
>
> i off
these are excellent answers.
i offer a harsher one:* the wrong answer faster is not optimization. *the
law of programming has correctness at its core--imagine reasoning about a
program where "if 5 < 7{stuff}" executed 50% of the time, or even 99.%
of the time. if it was faster, that simply wou
13 matches
Mail list logo
