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
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
