I’m pretty sure that if you look deeper not every call ends in “blocking” at least at the os level. Go uses green threads and relies on os level “poll type” support. It has the overhead of its own scheduler but in most cases it is more efficient than the os one.
> On Nov 15, 2019, at 9:52 PM, Kurtis Rader <kra...@skepticism.us> wrote: > > >> On Fri, Nov 15, 2019 at 7:27 PM Vincent Blanchon >> <blanchon.vinc...@gmail.com> wrote: > >> I was wondering about the behavior of syscalls. It looks like Go always >> wraps syscall - whatever blocking or not - with calling entersyscallblock() >> and exitsyscall() later. The first one automatically detaches M from the P >> when exit tries to acquire the same P or move the G to the global queue. In >> the case of non-blocking syscall, why do we have to detach M from the P? > > I can't speak to the rationale for Go's behavior. But whether a particular > syscall can ever block is a more difficult question than you seem to think. > And don't forget about CPU context switches. > > -- > Kurtis Rader > Caretaker of the exceptional canines Junior and Hank > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD-Asd562aLVDssQWvS9JsOK8q2Zd_2rGJ2PwLm1zG1hgQ%40mail.gmail.com. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/A4A94193-85C2-4960-AFED-246B207DA639%40ix.netcom.com.
