[Haskell-cafe] Re: standard poll/select interface

[Simon Marlow]

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