On Wed, Dec 19, 2018 at 6:52 PM robert engels <reng...@ix.netcom.com> 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, djad...@gmail.com 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 golang-nuts+unsubscr...@googlegroups.com.
> 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 golang-nuts+unsubscr...@googlegroups.com.
> 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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to