If you have many erlang actors waiting on IO, does the runtime automatically epoll all those file descriptors?
Most things in Haskell work this way. If you wanted to get epoll behaviour without actually calling epoll yourself, you could spawn a ton of processes to wait on different sockets or whatever and then just have them write into an STM container when they receive anything. The thread receiving from x million different clients or whatever just keeps reading from the STM container.
Of course, at large scale you would probably just use epoll directly and save on the few hundred bytes per thread overhead.
It's been a while now and I don't remember the details, sorry. To the best of my recollection, the BEAM VM won't do a blocking select(2). Or maybe it forces use of poll(2) when cross-compiling? Basically, the gist is that it breaks the BEAM scheduler to block on I/O for longer than a very short time, and the file read code is pretty deeply internal, so you just can't do it (network sockets are a very special exception). You can poll a file (that is, repeated reads), but you can't block and wait for, e.g. sysfs_notify. Since all Erlang threads are green threads, there's no way to accomplish a blocking read within the auspices of the VM. Thus, the C node.
My goal was to reduce the time between (physical) interrupt and Erlang thread response because I was trying to make sure I didn't miss an event.
Most things in Haskell work this way. If you wanted to get epoll behaviour without actually calling epoll yourself, you could spawn a ton of processes to wait on different sockets or whatever and then just have them write into an STM container when they receive anything. The thread receiving from x million different clients or whatever just keeps reading from the STM container.
Of course, at large scale you would probably just use epoll directly and save on the few hundred bytes per thread overhead.