On Wed, Oct 10, 2018 at 10:00 AM, robert engels <reng...@ix.netcom.com> wrote: > > Ah, thanks. The read first, then possible deschedule/poll threw me. > > Doesn’t this mean though that as network traffic becomes very high, that the > connections might starve because the number of actual threads is capped > (GOMAXPROCS) - it would seem you pair the scheduling penalty twice this way, > once in OS kernel, and again in the Go scheduler ? Doesn’t the Go scheduler > than have to be as “fair” as the OS scheduler - seems complex and a possible > source of obscure starvation bugs. > > Does this mean that if my ‘fd’ is always ready (in a Go routine reading a > socket) - because lots of data coming in - I will never deschedule ? In an > alternative environment, if I wrote C and had multiple FDs in a poll, in can > ensure that they are read in order - is that happening behind the scenes ? > > Thanks, just curious more than anything.
The Go scheduler will preempt goroutines that have been running for more than 10ms. Ian -- 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.
