I have made a prototype for overlapped IO that works with a modified version of Takano Akio's SSC library. I have been trying to add it to GHC's IO implementation but there are some issues. Instead of file descriptors windows handles are needed. The GHC handle implementation is currently based around fd's and many functions would need a separate windows API version. In some cases there is no simple conversion of existing functionality like the binary/text modes. An additional complication is that Haskell handles can be a lot of things other than files. Finally, a threaded rts is needed for the worker pool that processes the IO completions, so the current single threaded IO support must also remain. So for now i am focusing on testing and improving the prototype with a separate IO library. Best regards, Felix
Felix Martini wrote:
I have made a prototype for overlapped IO that works with a modified version of Takano Akio's SSC library.
Great! (I don't know what Takano Akio's SSC library is though)
I have been trying to add it to GHC's IO implementation but there are some issues. Instead of file descriptors windows handles are needed.
Yes, I thought that might be a problem. You will probably have to replace the existing FD in a Handle with a more complex type, maybe something like type WinHandle = FileHandle HANDLE | Socket FD perhaps pipes fit into FileHandle, I'm not sure. Maybe there should be an alternative for Console? I think we should be avoiding the CRT for I/O and using Win32 exclusively. I can believe this might be a lot of work, though.
The GHC handle implementation is currently based around fd's and many functions would need a separate windows API version. In some cases there is no simple conversion of existing functionality like the binary/text modes.
binary/text would have to be implemented in the Haskell IO library?
An additional complication is that Haskell handles can be a lot of things other than files. Finally, a threaded rts is needed for the worker pool that processes the IO completions, so the current single threaded IO support must also remain.
At least getting the threaded RTS version working first would be a good step, then we can think about how to do the single-threaded version. Cheers, Simon
Hi all, Overlapped IO support for files and sockets is now in place in my test version of ghc-head. File functions use the win32 api and large files and Unicode filenames are supported (i'm not sure if ghc currently supports that for Windows). I've addded a new type Hdl which is an alias for FD on non-Windows systems and WinHdl on Windows. That way many functions in GHC.Handle can remain generic. WinHdl is similar to the WinHandle type in Simon's post. I do have a bug where i can't locate the problem. GHCi works fine after limited testing, but when compiling a trivial program with GHC i get the following during the linking stage: ghc: fd:1880: lazyRead: invalid argument (Bad file descriptor) ghc: fd:1888: lazyRead: invalid argument (Bad file descriptor) After googling for similar bug reports it seems that it has to do with standard handles and the finalizer. But the code for standard handles and consoles is largely untouched. Also some advice on the best way to debug things like this would be welcome because compiling the complete GHC is rather slow on my single processor pc. Regards, Felix
participants (2)
-
Felix Martini -
Simon Marlow