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. > On Oct 10, 2018, at 11:45 AM, Ian Lance Taylor <i...@golang.org> wrote: > > On Wed, Oct 10, 2018 at 9:35 AM, robert engels <reng...@ix.netcom.com> wrote: >> >> It was my understanding that all IO in Go was async, and that behind the >> scenes when you made a network read, it enqueued the fd, descheduled the Go >> routine, and performed a select/poll on some other thread, then based on >> the select, it would rescheduled the proper Go routine to perform the read. >> >> But as I trace through the stdlib into UDPConn and down, I eventually see it >> make a Syscall6 using RECV_FROM - so I don’t see any of the ‘select/poll’ >> multiplexing? >> >> Is this reading correct ? Was this previous behavior that was removed ? > > I assume you traced it down to (*FD).ReadFrom in the internal/poll > package? That method will call the recvfrom system call first. If > that succeeds, great. If that returns EAGAIN, then at that point we > queue the descriptor with the runtime poller. That is, we keep all > descriptors in non-blocking mode, and optimistically try each > operation once. Only if the operation would block do we shift to > using the poller. > > 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.
