I had written a really long answer, but I suspect I may be misunderstanding what you are proposing. (Apologies if I misunderstand you here, but if I am misunderstanding you, then my long answer would have been even more patronising than i worry this already is.)
You have some code you wish to run each timer event. In a large system there may be a great many things that you want to run on some multiple count of this timer event. At the moment the code you wish to run is in a go routine that (I am assuming) waits for a channel event to run. Therefore you have many routines waiting to be triggered by a number of channel events. Instead you believe it would be better to register a (lambda?) function you wish to run on each timer event so that rather than having to do a full cpu context swap between threads, you could instead simply jump to the code that needs running. Best Regards Chris On Friday, 11 August 2017 06:32:33 UTC+1, Cholerae Hu wrote: > > Currently if we use timer or something, runtime will start a new goroutine > to do timerproc works. Why can't we check timer heap in each iteration of > sysmon if any timer exists? This may reduce some context switchs, I think. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
