Endangered I/O operations
Wed, 16 May 2001 17:46:57 +0100
I'm currently re-implementing GHC's I/O library, and I'd like to get
people's opinions on the following I/O extensions currently provided by
GHC - should we continue to provide them or not.
This was designed to be a way to have one handle automatically flushed
before we flush another handle (eg. outputting to stderr causes stdout
to be flushed first). The current implementation has a number of
problems: errors and blocking arenn't handled properly when doing the
connected flush. If no-one is using it, I'd like to get rid of it.
This is a cunning hack to allow you to temporarily redirect one handle
to another, like 2>&1 in shell speak. I'm dubious as to whether it
works consistently - there's certainly not enough error checking in the
implementation, so if no-one is using it I'd like to drop it.
3. IOExts.hGetBuf, IOExts.hPutBuf,=20
These are the "non-blocking" versions of hGetBufFull, hPutBufFull etc.
I can't remember why we have both blocking and non-blocking versions,
although I distinctly remember implementing and documenting them :-) If
anyone is using, or knows of a good use for, the non-blocking versions,
then I'll keep them. Otherwise, I'd like to rename hGetBufFull to
hGetBuf, and similarly for the others.