<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>You are right that the Go runtime does not care about system load. I suppose it was designed for server applications running in Docker containers or virtual machines. In this world, system load does not matter because a chunk of system resources will be allocated exclusively to the application.</div><div><br>On Oct 31, 2016, at 2:25 PM, Jean-Daniel <<a href="mailto:dev@xenonium.com">dev@xenonium.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">Le 31 oct. 2016 à 09:21, Darren Mo via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Something to keep in mind… once <a href="https://bugs.swift.org/browse/SR-2905" class="">SR-2905</a> is resolved, it will be feasible to write Linux server applications in a synchronous manner.<div class=""><br class=""></div><div class="">How does this work? Dispatch work items are scheduled onto a pool of kernel threads. If a work item makes a blocking system call, the kernel thread will be blocked. Ideally, the work item scheduler will start a new kernel thread to take the place of the blocked thread. This is only possible if the scheduler can be triggered at the moment the blocking system call is made. A Linux kernel module is required for this to work in Swift.</div><div class=""><br class=""></div><div class="">This ideal threading model is the main selling point of Go. Go developers can write their code in a synchronous manner without any performance tradeoff. (You might be wondering why Go does not need a kernel module. The reason is all the system calls go through the Go runtime before reaching the kernel.)</div></div></div></blockquote><div><br class=""></div>The main benefit of GCD and worker threads is that as the threads are managed by the kernel, it can accommodate thread allocation and io scheduling by considering the system load as a whole, and not only the process load.</div><div>I’m not familiar with go enough to know how the runtime cope with this, but from the description it look like it don't care about other processes when it managed goroutines.</div><div><br class=""></div><div><br class=""></div></div></blockquote></body></html>