3 ms·
Yes, and VMS had asynchronous system traps for I/O in 1977.² ³ And yes, of course? Erlang could do scalable async I/O in 1988. Alice ML and Erlang both emulat
by PeCaN 10y ago
Yes, and VMS had asynchronous system traps for I/O in 1977.² ³
And yes, of course? Erlang could do scalable async I/O in 1988.
Alice ML and Erlang both emulate async I/O by having a few OS level threads each switching between a large number of userspace/VM threads. They queue I/O operations then preempt VM threads when results are ready. For a while that was the only sane way around the clusterfuck that is async I/O on *nix. It still scales fine and I think there's rather little interest in converting either Alice ML or Erlang to libevent/libev/libuv.
¹ The initial Erlang VM was very slow, but the I/O model was there. BEAM was created in 1992 and was fast enough for Ericsson to use in production.
² NT and VMS were both designed by David Cutler, who is more or less the father of asynchronous I/O at the OS level.
³ Incidentally, if you think async I/O in 1977 was advanced, you should look at AS/400 or VOS sometime.
- Const-me 10y ago> It still scales fine Only 1024 sockets per select because FD_SETSIZE constant? How’s that scales fine? You have 10k sockets = you need 10 native threads, with 10 native stacks, on a quad code machine each of them is guaranteed to be out of CPU cache when IO completes. Not fine, very inefficient. > there's rather little interest in converting either Alice ML or Erlang to libevent/libev/libuv. Well, Erlang developers don’t care about windows. And for BSD, Linux and Solaris they already support native event-based async IO for many years. They call the feature “kernel poll”. > if you think async I/O in 1977 was advanced I aware on some systems it was widely used. Just not on the mainstream *nix systems where that Alice ML ran in 2000.