Re:GHC 7 is out: Haskell 2010 support; LLVM backend; new opt...
by pufuwozu on Tuesday November 16, 2010 @12:01AM
(#1909111)
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.
From http://www.serpentine.com/bos/files/ghc-event-manager.pdf
Re:GHC 7 is out: Haskell 2010 support; LLVM backend; new opt...
by tibbe on Tuesday November 16, 2010 @07:21AM
(#1909840)
We need a Windows user who's willing to drive it. Bryan and I are happy to apply patches but neither of us are Windows developers.
Re:GHC 7 is out: Haskell 2010 support; LLVM backend; new opt...
by ch on Tuesday November 16, 2010 @09:50AM
(#1910182)
Sadly I too am not a Windows developer. That said, I've never before had such a compelling reason to become one.
I do hope that someone more familiar with Windows takes up the torch.
Re:GHC 7 is out: Haskell 2010 support; LLVM backend; new opt...
by stonemetal on Tuesday November 16, 2010 @09:59PM
(#1912714)
I would but I can't quite figure out GHC's build process.
Re:GHC 7 is out: Haskell 2010 support; LLVM backend; new opt...
by stonemetal on Tuesday November 16, 2010 @07:16AM
(#1909831)
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?