> Memory mapped I/O is also an incredibly important feature for I/O performance, and there's almost no reason to use traditional I/O on 64-bit. However, it's a no-go with M:N scheduling because the page faults block the thread.
This is more or less why Java switched to native threads a decade and a half ago. Although in that case, it was page faults from hitting swap rather than memory-mapped IO. And in both cases, compatibility with existing native code which makes blocking system calls was also a consideration. It's reassuring that Rust is following a path well-worn by other serious languages.
Now it's just a question of waiting for Go and Node to do the same.
Note, be very careful with "mmap is the fastest way to do IO". That's not true 90% of the time.
mmap is the fastest way to do IO when the OS already has file contents in memory and it's more than a few pages so setup of mmap() call is cheaper than memcopying data from kernel space.
However mmap is terrible for cold IO. The problem is that mmap is IO-by-sideeffect-of-pagefaults. One has to use madvise() very carefully to make sure that the OS reads useful parts of a file during a pagefault. mmap style of IO is also susceptible to access-pattern bugs, eg even the Linux toolchain gets it deadly wrong and ends up doing IO backwards: https://blog.mozilla.org/tglek/2010/05/27/startup-backward-c....
mmap is even worse on Windows. Windows has no madvise(), OSX equivalent is pathetic. OSX and Windows read mmaped files in bizzarely small chunks, etc.
Google has been pushing for performance improvements in native threads for a similar reason. If that's successful, I think the plan is for Go to switch too, but I can't find any links about it atm.
That might be the talk you are thinking about. I am keeping an eye on this. If we can have our cake and eat too w.r.t green threads and performance I will be very happy.
