4 ms·

I guess if we're nitpicking, then here's another one: > Looking near the top of the output, we see that Haskell's run-time system was able to create 100,000 th

by guntars 10y ago

I guess if we're nitpicking, then here's another one: > Looking near the top of the output, we see that Haskell's run-time system was able to create 100,000 threads while only using 165 megabytes of memory. We are roughly consuming 1.65 kilobytes per thread. Those are not the same kind of threads that the author is talking about in the beginning of the article. Those a green threads and as such are multiplexed to much smaller amount of real system threads to do work in parallel. What that means is that they, for example, can't all make a system call at the same time. Go has the same issue.

wyager 10y ago
> What that means is that they, for example, can't all make a system call at the same time. Yes, they can. The Haskell IO manager knows how to handle this. http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask03...
- guntars 10y ago
  That's true with a caveat. It knows how to handle IO syscalls on systems where something like "epoll" or "kqueue" is available which, to be fair, is majority of what a typical server does. In the general case waiting for a syscall to return will block the system thread and no other green thread is going to be able to run on it.
  - wyager 10y ago
    > In the general case waiting for a syscall to return will block the system thread and no other green thread is going to be able to run on it. The runtime will migrate pending green thread actions to other OS threads. I don't remember what happens if you have as many blocked FFI calls as OS threads. The runtime might spawn more if you're using RTS -N. If you have RTS -Nn, where n is a number, I imagine it does block.
  - platz 10y ago
    The GHC Haskell runtime supports preemtive scheduling of cooperative threads ("green threads"). In non-preemtive cooperative threading, threads yield to each other. However, when a thread goes into a syscall, it no longer has the control to yield. The only way to wake up from a syscall (and thus to decide wether another thread should be scheduled, inside the runtime, and thus to get preemtive scheduling), is to send a signal to the process that's blocked in the syscall; then the syscall gets interrupted with EINTR and the runtime can do its scheduling decision, and then resume the syscall if needed. This signal sending is done by setting up a periodic "timer signal" that sends SIGALRM to the process every 10 ms (by default). http://man7.org/linux/man-pages/man2/timer_create.2.html http://man7.org/linux/man-pages/man2/timer_create.2.html
    - guntars 10y ago
      Thanks, I did not know this.

by guntars 10y ago

wyager 10y ago

> What that means is that they, for example, can't all make a system call at the same time. Yes, they can. The Haskell IO manager knows how to handle this. http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask03...

guntars 10y ago
That's true with a caveat. It knows how to handle IO syscalls on systems where something like "epoll" or "kqueue" is available which, to be fair, is majority of what a typical server does. In the general case waiting for a syscall to return will block the system thread and no other green thread is going to be able to run on it.
- wyager 10y ago
  > In the general case waiting for a syscall to return will block the system thread and no other green thread is going to be able to run on it. The runtime will migrate pending green thread actions to other OS threads. I don't remember what happens if you have as many blocked FFI calls as OS threads. The runtime might spawn more if you're using RTS -N. If you have RTS -Nn, where n is a number, I imagine it does block.
- platz 10y ago
  The GHC Haskell runtime supports preemtive scheduling of cooperative threads ("green threads"). In non-preemtive cooperative threading, threads yield to each other. However, when a thread goes into a syscall, it no longer has the control to yield. The only way to wake up from a syscall (and thus to decide wether another thread should be scheduled, inside the runtime, and thus to get preemtive scheduling), is to send a signal to the process that's blocked in the syscall; then the syscall gets interrupted with EINTR and the runtime can do its scheduling decision, and then resume the syscall if needed. This signal sending is done by setting up a periodic "timer signal" that sends SIGALRM to the process every 10 ms (by default). http://man7.org/linux/man-pages/man2/timer_create.2.html http://man7.org/linux/man-pages/man2/timer_create.2.html
  - guntars 10y ago
    Thanks, I did not know this.