Fantastic work. The improvements to the I/O manager are well worth the price of admission.
I'm curious, is work underway to see similar gains made in the I/O manager on Windows?
Does Windows provide a similar construct as 'select()' and also something equivalent to the newer epoll/kqueue systems, such that boosting the I/O manager on Windows will be rather trivial, or is the Windows I/O subsystem so different that the GHC I/O manager must be designed completely differently on that platform?
The Windows operating system presents a difficulty to our current design. Its support for scalable event notification is based around I/O completion ports, which are integrated tightly with the Windows threading mechanism, and which would require a considerable amount of replumbing to support.
Windows provides select just like everybody else. High performance IO in windows is done with IO Completion Ports it is a little more complicated than epoll.
I'm curious, is work underway to see similar gains made in the I/O manager on Windows?
Does Windows provide a similar construct as 'select()' and also something equivalent to the newer epoll/kqueue systems, such that boosting the I/O manager on Windows will be rather trivial, or is the Windows I/O subsystem so different that the GHC I/O manager must be designed completely differently on that platform?