[go-nuts] Go's scheduler always “stuck” after certain time when executing the code below

Hi, I found when running this code below (play ): package main import "fmt" import "runtime" import "time" type callRet struct { ret int } type callIn struct { ret_chan chan *callRet arg1 int } func caller(call_in_c chan *callIn, arg1 int) int { ret_c

[go-nuts] Re: Go's scheduler always “stuck” after certain time when executing the code below

PS: go func() { for { } }() The reason of this code above is that I want to test the channel's latency when some 'indecency' goroutine is seizing several whole OS threads. On Wednesday, 21 June 2017 11:40:12 UTC+8, Ronald wrote: > > Hi, I found when running this code below

[go-nuts] Re: Go's scheduler always “stuck” after certain time when executing the code below

If* proposition P1 is always true on golang, *then we could deduce that golang is not good at cpu intensive applications, of course we could unload the jobs to Cgo, but that would be no consistency at all. On Wednesday, 21 June 2017 13:12:12 UTC+8, Ronald wrote: > > I found this:

[go-nuts] Re: Go's scheduler always “stuck” after certain time when executing the code below

Hi Dave, thanks for your reply :) Could you please have one more look on this ? Looking forward to hear the answer from you, thanks a lot. On Wednesday, 21 June 2017 12:55:23 UTC+8, Dave Cheney wrote: > > Yes, this is

[go-nuts] Re: Go's scheduler always “stuck” after certain time when executing the code below

ing staff (including pending go routines and other core business) to other idle threads when some 'indecency' goroutine is seizing the several busiest threads? On Wednesday, 21 June 2017 11:45:20 UTC+8, Ronald wrote: > > PS: > > go func() { > for { > } > }() > >

[go-nuts] Re: Go's scheduler always “stuck” after certain time when executing the code below

On Wednesday, 21 June 2017 12:55:23 UTC+8, Dave Cheney wrote: > > Yes, this is expected. Don't write infinite loops like that. Sorry Dave, but I still couldn't get why it would 'stuck' for the very first piece of code. Of course it would be pretty reasonable that the go process would be

[go-nuts] Re: Go's scheduler always “stuck” after certain time when executing the code below

> > > Replace : > go func() { for { > } > }() > With: > > go func() { > ct := 0 > t1 := time.Now().UnixNano() > for { > ct++ > if ct%6 == 0 { > t2 := time.Now().UnixNano() >

Re: [go-nuts] Re: Go's scheduler always “stuck” after certain time when executing the code below

It seems really pointless if you've got lots of work to do to have to sit > in a delay. > Some CPU intensive application indeed sit here and do some massive mathematic calculation and memory manipulation.There is too many examples, say some de/en-coding worker for example. > Would not a

Re: [go-nuts] Re: Go's scheduler always “stuck” after certain time when executing the code below

fter using cpu intensive codes in golang comparing to unload it to cgo directly. And this kinda penalty could definitely cause the unstability of go application which has some really massive things to handle in pure go codes. On Wednesday, 21 June 2017 20:49:59 UTC+8, Ronald wrote: >

[go-nuts] [ANN]`go tool trace -diagreedy` Diagnoses the CPU greediest Top N goroutines to gain shorter and more stable GC pause latency

This project added a new sub-option to the `go tool trace` named "diagreedy" which could "diagnose and find out the cpu greediest several goroutines". This tool already helped us tracked down several deep hidden problems in our go applications and achieved more stable and shorter GC pause

[go-nuts] Re: Go's scheduler always “stuck” after certain time when executing the code below

Thanks to all of you :) Recently I have implemented a sub-option in the `go tool trace` named "diagreedy" which means "diagnoses and finds out the greediest several goroutines". This tool already helped us track down several deep hiden problems in our go applications and achieved more

Re: [go-nuts] Isn't it better just to panic when you send/recv on a nil channel instead of forever blocking?

On Friday, 5 May 2017 13:26:33 UTC+8, Ronald wrote: > > Wouldn't it better to just keep the nil channels out of the cases in the > select > statement at the very beginning like epoll_wait does? > (I think the select statement in golang is very similar to the epoll_wait &

Re: [go-nuts] Isn't it better just to panic when you send/recv on a nil channel instead of forever blocking?

? On Friday, 5 May 2017 12:54:18 UTC+8, Jesse McNelis wrote: > > On Fri, May 5, 2017 at 1:35 PM, Ronald <yunth...@gmail.com > > wrote: > > > > So the question: > > > > Isn't it better just to throw a panic when user send/recv on a nil

[go-nuts] Isn't it better just to panic when you send/recv on a nil channel instead of forever blocking?

The program will simply panic when you write to a closed channel, because that kind of operations is just nonsense after the action of closing the channel. I afraid that the situation is similar to the nil channel operation.Because the nil channel is not been initialized yet, so there is must

[go-nuts] [generics] I think it's better have higher perfomance than lower compiling time

Just if perfomance will decrease with every release/version, it'd be not really good, and it's might be necessary to pay more attention to this -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving