5 ms·

That is exactly what Go does by default. Any time a blocking operation is performed, Go either leaves the OS-level thread blocked there and switches away, or ha

That is exactly what Go does by default. Any time a blocking operation is performed, Go either leaves the OS-level thread blocked there and switches away, or hand the blocking operation to an internal thread which is running epoll for the whole process. The end result is much easier than Python/NodeJs because there is no explicit "async/await" or deferred-style programming. You simply write linear code and any blocking operation (at the syscall level) is transparently handled.

hannofcart 9y ago
Thanks for taking the time to write this response. The more I hear about Go's features, the more I seem to like it.
- wyager 9y ago
  FYI, this is not unique to Go. A number of languages implement lightweight threads in the same way (roughly), like erlang or Haskell. It’s all epoll or other efficient polling primitives under the hood.
  - weberc2 9y ago
    I'm of the impression that there's an important difference between Go and Haskell's models--namely that Go is M:N threaded and Haskell is not; however, I don't entirely understand the significance of the difference, so hopefully someone else can comment and enlighten me.
    - joel_ms 9y ago
      Are you sure about Haskell not having m:n threads? Because it's seems weird, considering GHC is listed as one of a few examples on wikipedia: https://en.m.wikipedia.org/wiki/Thread_(computing)#M:N_.28hybrid_threading.29 https://en.m.wikipedia.org/wiki/Thread_(computing)#M:N_.28hy...
      - weberc2 9y ago
        No, I'm not sure. :) I may have incorrectly assumed that the definition of M:N threads includes movable application threads (e.g., Go's scheduler can move goroutines from one kernel thread to another).
pcwalton 9y ago
In other words, Go uses threads. There's nothing semantically unique to Go about this model.
- cdoxsey 9y ago
  Go uses an m:n thread model. Goroutines are multiplexed onto a smaller number of os-level threads. They're sort of like threads, but they have a simplified programming model (There is no thread-level storage for example).
  - pcwalton 9y ago
    Goroutines are threads. They're just not kernel-level threads. There have been implementations of pthreads that used an M:N model, for instance.
    - weberc2 9y ago
      For my information, why is M:N so successful for Go and not for pthreads? Is M:N more practical for systems with a particular kind of garbage collector?
      - pcwalton 9y ago
        In my opinion, it's because the Go team put a ton of effort into getting M:N working and didn't rigorously evaluate any other alternatives in Go, once moving GC was implemented. I'm not convinced that 1:1 wouldn't have been a perfectly reasonable implementation strategy for Go.
        weberc2 9y ago
        This is surprising. It seems like Go gets pretty high praise from all over for its threading model, and it seems like there are relatively few high-performance servers that are built with 1:1. Am I wrong about that? If not, what explains this?
- 9y ago

hannofcart 9y ago

Thanks for taking the time to write this response. The more I hear about Go's features, the more I seem to like it.

wyager 9y ago
FYI, this is not unique to Go. A number of languages implement lightweight threads in the same way (roughly), like erlang or Haskell. It’s all epoll or other efficient polling primitives under the hood.
- weberc2 9y ago
  I'm of the impression that there's an important difference between Go and Haskell's models--namely that Go is M:N threaded and Haskell is not; however, I don't entirely understand the significance of the difference, so hopefully someone else can comment and enlighten me.
  - joel_ms 9y ago
    Are you sure about Haskell not having m:n threads? Because it's seems weird, considering GHC is listed as one of a few examples on wikipedia: https://en.m.wikipedia.org/wiki/Thread_(computing)#M:N_.28hybrid_threading.29 https://en.m.wikipedia.org/wiki/Thread_(computing)#M:N_.28hy...
    - weberc2 9y ago
      No, I'm not sure. :) I may have incorrectly assumed that the definition of M:N threads includes movable application threads (e.g., Go's scheduler can move goroutines from one kernel thread to another).

pcwalton 9y ago

In other words, Go uses threads. There's nothing semantically unique to Go about this model.

cdoxsey 9y ago
Go uses an m:n thread model. Goroutines are multiplexed onto a smaller number of os-level threads. They're sort of like threads, but they have a simplified programming model (There is no thread-level storage for example).
- pcwalton 9y ago
  Goroutines are threads. They're just not kernel-level threads. There have been implementations of pthreads that used an M:N model, for instance.
  - weberc2 9y ago
    For my information, why is M:N so successful for Go and not for pthreads? Is M:N more practical for systems with a particular kind of garbage collector?
    - pcwalton 9y ago
      In my opinion, it's because the Go team put a ton of effort into getting M:N working and didn't rigorously evaluate any other alternatives in Go, once moving GC was implemented. I'm not convinced that 1:1 wouldn't have been a perfectly reasonable implementation strategy for Go.
      - weberc2 9y ago
        This is surprising. It seems like Go gets pretty high praise from all over for its threading model, and it seems like there are relatively few high-performance servers that are built with 1:1. Am I wrong about that? If not, what explains this?
9y ago