3 ms·
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
by 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 agoThe 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 agoThanks, I did not know this.