Re: [go-nuts] Re: Long running task in select case

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

Re: [go-nuts] Re: Long running task in select case

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

Re: [go-nuts] Re: Long running task in select case

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

Re: [go-nuts] Re: Long running task in select case

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.

Re: [go-nuts] Re: Long running task in select case

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

Re: [go-nuts] Re: Long running task in select case

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

Re: [go-nuts] Re: Long running task in select case

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

Re: [go-nuts] Re: Long running task in select case

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

[go-nuts] Re: Long running task in select case

I came to the following solution for my long running tasks, using go-routines & the context package, https://play.golang.org/p/2V_29lHt4Wn package main import ( "context" "fmt" "time" ) //LongRunningTask func LongRunningTask(ctx context.Context, index int) (err error) { // we'll si

Re: [go-nuts] Re: Long running task in select case

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

Re: [go-nuts] Re: Long running task in select case

> > 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

Re: [go-nuts] Re: Long running task in select case

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

Re: [go-nuts] Re: Long running task in select case

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

Re: [go-nuts] Re: Long running task in select case

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

[go-nuts] Re: Long running task in select case

Hi all, In this particular case, this is a toy example of course, but for this toy example, it is absolutely a case where the performance of the synchronization primitive literally does not matter at all. (If I followed here, the intent is seemingly to watch a long running task, and the example

[go-nuts] Re: Long running task in select case

On Saturday, March 17, 2018 at 10:37:48 AM UTC-4, matthe...@gmail.com wrote: > > I think the second example alternative given (playground link above) has a >> data race? > > > I’m not surprised that the race detector sees something (a read can happen > during a write of the checked bool) but I

[go-nuts] Re: Long running task in select case

> > I think the second example alternative given (playground link above) has a > data race? I’m not surprised that the race detector sees something (a read can happen during a write of the checked bool) but I don’t think this could actually cause problems because the var’s memory value will a

[go-nuts] Re: Long running task in select case

> > *> "Here's another way: https://play.golang.org/p/gEDef3LolAZ > "* Hi all, I think the second example alternative given (playground link above) has a data race? Sample race detector run just now. (The two reports are inverses of each other: read t

[go-nuts] Re: Long running task in select case

Leaving aside the channel being non-nil, none of the others are a clear way to solve this. They all involve either repeatedly checking on a timer or checking the value of another field (like polling) to see whether the long running task should be stopped. Is there no other way to do this then?

[go-nuts] Re: Long running task in select case

> > While this is running, your select won't be receiving on the quit > channel, even if it is non-nil. > If you want to be able to cancel it, you'll need to make the code in > the loop responsive to the quit channel > (for example, by using a select like you're using in f already). The def