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 call to runtime.Gosched() be more efficient. That way you > accept that you yeald to other procs, but still allow yourself to be > rescheduled immediately if there is nothing else in the queue? > This the point. The more runtime.Gosched() function calls you put into the places of your CPU intensive go codes, the less latency it could be, but the CPU cost on the core go runtime is unwanted *increasing *simultaneously (the cost on go core runtime is the less the better from the point of view of the go applications). So there is unresolved conflict. But as there is still many idle GOMAXPROCS left behind idly, I can not see any reason for the go core runtime to suspend all the other goroutines just because there is one 'indecency' cpu intensive goroutine is fully occupying just one os thread. There must something could be done at the inner of go scheduler that could optimize such scenarios. -- 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.
