Then something is broken on the implementation. 10x overhead does not seem realistic.
> On Dec 19, 2018, at 9:50 PM, Ian Lance Taylor <[email protected]> wrote: > >> On Wed, Dec 19, 2018 at 6:52 PM robert engels <[email protected]> wrote: >> >> I don’t think the analysis is correct in the issue cited. No one mentions >> just using usleep() as the system call like a C program would, at least for >> time.Sleep(), and block the calling thread. > > That doesn't scale to large numbers of goroutines. > > >> For the timer based select, it is more difficult, and it seems the timerfd >> is the best solution - but I would instead proposed a timer thread - that >> manages all timers, and interacts with the scheduler as an external event - >> that is it wakes up based on the earliest expiration timer. > > That's more or less how the runtime works today, although it doesn't > use timerfd and there are up to 64 timer threads. > > Ian > > >> On Dec 19, 2018, at 7:58 PM, [email protected] wrote: >> >> see https://github.com/golang/go/issues/27707 >> >> >> -- >> 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. >> >> >> -- >> 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. -- 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.
