Bulat Ziganshin wrote:
SM> I don't think async I/O is a stream transformer, fitting it into the SM> stream hierarchy seems artificial to me.
yes, it is possible - what i'm trying to implement everything as tranformer, independent of real necessity. i really thinks that idea of transformers fit every need in extending functionality
it is a list of my reasons to implement this as transformer:
1) there is no "common FD" interface.
Well, there's the unix package. In theory, System.IO should layer on top of System.Posix or System.Win32, depending on the platform. In practice we extract the important bits of System.Posix and put them in the base package to avoid circular dependencies. The current implementation could use some cleaning up here (eg. FD vs. Fd).
on the other side, reasons for your proposal, as i see:
1) if FD will incorporate async i/o support, the System.FD library will become much more useful - anyone using low-level fd* functions will get async i/o support for free
but there is another defeciency in the System.FD library - it doesn't include support for the files>4Gb
Yes it does!
and files with unicode filenames under Windows.
Under Windows I believe we should be using a Win32-specific substrate on which to build the I/O library.
it seems natural to include this support in fd* too.
now let's see. you are proposing to include in fd* implementation support for files, sockets, various async i/o methods and what's not all. are you not think that this library will become a successor of Handle library, implementing all possible fucntionality and don't giving 3rd-party libraries chances to change anything partially?
Not at all - I'm just suggesting that there should be an API to FD-based I/O, and that concurrency-safety can be layered on top of this, providing exactly the same API but with concurrency-safety built in.
i think that you mix two things - readNonBlockingFD call that can fill buffer only partially and readAsync call that use some I/O manager to perform other Haskell threads while data are read
Why do you want to expose readAsync at all?
well, i agree that should be two GetBuf variants in the Stream interface - greedy and non-greedy. say, vGetBuf and vGetBufNonBlocking. vPutBuf also need two variants?
then, may be LineBuffering and BlockBuffering should use vGetBufNonBlocking and vGetBuf, respectively?
but i don't know anything about implementation. is the difference between readNonBlockingFD and readFD calls only in the O_NONBLOCK mode of file handle, or different functions are used? what for Windows? for sockets? how this interacts with the async i/o?
Never mind about this - just assume readNonBlockingFD as your lowest-level primitive, and we can provide an implementation of readNonBlockingFD that uses select/poll/whatever underneath. I imagine we'll stop using O_NONBLOCK. The Windows version will look different at this level, because we should be using Win32 native I/O, i.e HANDLE instead of FD, but it will have a primitive similar to readNonBlockingFD, also concurrency-safe. Cheers, SImon