> just add a function call occasionally depending on your required latency bound
Thanks Jesper for your all detailed explanation. I quite agree with your point of view and conclusion. One thing left here should to be discussed is about the go scheduler's unwanted behaviour. Unwanted behaviour of the scheduler: After go run the codes at the topmost of this thread, we got: $ time go run na.go > heartbeat... > 1000 > 2000 > 3000 > 4000 > 5000 > 6000 > 7000 > 8000 > 9000 > 10000 > 11000 > heartbeat... > 12000 > 13000 > heartbeat... > 14000 > 15000 > 16000 > 17000 > 18000 > 19000 > heartbeat... > ^Csignal: interrupt > real 0m0.779s > user 0m0.720s > sys 0m0.152s (*The process stuck here forever and no new outputs anymore*) As the runtime.GOMAXPROCS is 5 now, why can't the scheduler just let the other several goroutines which is already pending all switch to the 4 left idly goroutine 'slots' and run on instead of suspend forever? I think there is probably some design flaw about it. On Wed, Jun 21, 2017 at 10:18 PM, Sen Han <yunthana...@gmail.com> wrote: > > just add a function call occasionally depending on your required latency > bound > > Thanks Jesper for your all detailed explanation. I quite > agree with your point of view and conclusion. > > One thing left here should to be discussed is about the > go scheduler's unwanted behaviour. > > Unwanted behaviour of the scheduler: > > After go run the codes at the topmost of this thread, we got: > > $ time go run na.go >> heartbeat... >> 1000 >> 2000 >> 3000 >> 4000 >> 5000 >> 6000 >> 7000 >> 8000 >> 9000 >> 10000 >> 11000 >> heartbeat... >> 12000 >> 13000 >> heartbeat... >> 14000 >> 15000 >> 16000 >> 17000 >> 18000 >> 19000 >> heartbeat... >> ^Csignal: interrupt >> real 0m0.779s >> user 0m0.720s >> sys 0m0.152s > > > (*The process stuck here forever and no new outputs anymore*) > > As the runtime.GOMAXPROCS is 5 now, why can't the scheduler just > let the other several goroutines which is already pending all switch > to the 4 left idly goroutine 'slots' and run on instead of suspend forever? > I think there is probably some design flaw about it. > > On Wed, Jun 21, 2017 at 9:40 PM, Jesper Louis Andersen < > jesper.louis.ander...@gmail.com> wrote: > >> On Wed, Jun 21, 2017 at 5:40 AM Ronald <yunthana...@gmail.com> wrote: >> >>> Hi, I found when running this code below (play >>> <https://play.golang.org/p/XyxV_1f6Ri>): >>> >>> >>> You are looking at a property of a specific Go implementation, not a >> property of the language. >> >> Any system must define a set of "preemption points" at which you can >> switch out one process for another. Historically go only preempted on >> channel communication and (blocking) system calls. Later it also added >> preemption on function calls (it piggybacks on stack checks). Adding more >> preemption requires you to add checks inside loops so a loop eventually >> gets preempted, but the caveat is that this might slow you program down >> when you have a tight loop for which the compiler can prove no eventual >> bound. >> >> The current best workaround is to make sure that lengthy work >> periodically hits a preemption point some way or the other. Later versions >> of Go might solve this problem by adding those checks itself automatically >> to your programs to improve their latencies. >> >> Other concurrent languages use different methods: >> >> Erlang preempts like Go does currently, but since loops are implemented >> with recursion, you are sure to hit a preemption point every time you go >> round the loop. >> >> Haskell preempts on memory allocation and Haskell programs tend to >> allocate memory quite frequently. The exception is tight (fusioned) loop >> code on arrays. >> >> Go is doing a *far* better job here than almost every other programming >> language out there when it comes to fair scheduling. And there is a >> somewhat simple workaround: just add a function call occasionally depending >> on your required latency bound. >> >> >> >> > -- 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, visit https://groups.google.com/d/optout.
