Hello Simon, Friday, January 27, 2006, 7:25:44 PM, you wrote:
i'm now write some sort of new i/o library. one area where i currently lacks in comparision to the existing Handles implementation in GHC, is the asynchronous i/o operations. can you please briefly describe how this is done in GHC and partially - why the multiple buffers are used?
SM> Multiple buffers were introduced to cope with the semantics we wanted SM> for hPutStr. thank you. i was read hPutStr comments, but don't understood that this problem is the only cause of introducing multiple buffers SM> The problem is that you don't want hPutStr to hold a lock SM> on the Handle while it evaluates its argument list, because that could SM> take arbitrary time. Furthermore, things like this: SM> putStr (trace "foo" "bar") SM> used to cause deadlocks, because putStr holds the lock, evaluates its SM> argument list, which causes trace to also attempt to acquire the lock on SM> stdout, leading to deadlock. SM> So, putStr first grabs a buffer from the Handle, then unlocks the Handle SM> while it fills up the buffer, then it takes the lock again to write the SM> buffer. Since another thread might try to putStr while the lock is SM> released, we need multiple buffers. i don't understand the last sentence. you are said about problems with performing I/O inside computation of putStr argument, not about another thread? i understand that locks basically needed because multiple threads can try to do i/o with the same Handle simultaneously SM> For async IO on Unix, we use non-blocking read() calls, and if read() SM> indicates that we need to block, we send a request to the IO Manager SM> thread (see GHC.Conc) which calls select() on behalf of all the threads SM> waiting for I/O. For async IO on Windows, we either use the threaded SM> RTS's blocking foreign call mechanism to invoke read(), or the SM> non-threaded RTS has a similar mechanism internally. so, async I/O in GHC is have nothing common with "zero-wait operation" in single-threaded environment and can only help to overlap i/o in one thread with execution of other threads? SM> We ought to be using the various alternatives to select(), but we SM> haven't got around to that yet. yes, i read these threads and even remember Trac ticket about this. btw, in the typeclasses-based i/o library this facility can be added as additional middle layer, in the same way as buffering and Char encoding. i even think that it can be done as 3-party library, w/o any changes to the main library itself
moreover, i have an idea how to implement async i/o without complex burecreacy: use mmapped files, may be together with miltiple buffers.
SM> I don't think we should restrict the implementation to mmap'd files, for SM> all the reasons that Einar gave. Lots of things aren't mmapable, mainly. i'm interested because mmap can be used to speed up i/o-bound programs. but it seems that m/m files can't be used to overlap i/o in multi-threaded applications. anyway, i use class-based design so at least we can provide m/m files as one of Stream instances SM> My vision for an I/O library is this: SM> - a single class supporting binary input (resp. output) that is SM> implemented by various transports: files, sockets, mmap'd files, SM> memory and arrays. Windowed mmap is an option here too. i don't consider fully-mapped files as an separate instance, because they can be simulated by using window-mapped files with large window SM> - layers of binary filters on top of this: you could add buffering, SM> and compression/decompression. SM> - a layer of text translation at the top. SM> This is more or less how the Stream-based I/O library that I was working SM> on is structured. SM> The binary I/O library would talk to a binary transport, perhaps with a SM> layer of buffering, whereas text-based applications talk to the text layer. that's more or less close to what i do. it is no wonder - i was substantially influenced by the design of your "new i/o" library. the only difference is that i use one Stream class for any streams -- Best regards, Bulat mailto:bulatz@HotPOP.com