> 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.
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.
mmap has the worst error-handling semantics of all IO methods. Linux gives you a super-hard-to-wrap SIGBUS, Windows forces use of slightly-less-horrific SEH http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...
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.