RE: Endangered I/O operations
If you handle std{in,out,err} connectedness in other ways, I think you've covered 99.2% of the uses of hConnectTo. Neat idea borrowed from Korn & Vo's SFIO, but it hasn't proved to be all that useful.
I wasn't planning to handle connectedness at all. Is it important, do you think? (I'm not against the feature, just trying to avoid feeping creaturism...)
Yes, crucial I think - if stdout and stderr are connected to the same device, don't you want their output to be synchronised, e.g.,
main = putStr "foo" >> hPutStr stderr " bar"
should return "foo bar" on your TTY. Ditto for flushing stdout/stderr when peeking stdin.
You obtain the ordering properties by setting the handle to NoBuffering, otherwise you get buffered input/output. Wouldn't it be deviating from the report to do extra flushing in the buffered case? (this is something of a technicality, actually we already do non-report flushing in several cases and our line-buffered input isn't line-buffered at all). But I'm still not convinced we need to special case this. Cheers, Simon
Simon Marlow
....
You obtain the ordering properties by setting the handle to NoBuffering, otherwise you get buffered input/output. Wouldn't it be deviating from the report to do extra flushing in the buffered case?
The report is very silent about this, so I guess that reduces the question to what the end-user would prefer, (a) go non-buffered or make sure you call hFlush at the right time, or (b) have the IO implementation flush when required. I prefer (b), which is why I implemented this at the time, as it is more useable (and more efficient to boot). FWIW, notice that stdio implementations diverge on this issue too, all Win32 impls I've seen does the flushing for you, as did earlier impls of glibc, I seem to recall. --sigbjorn
participants (2)
-
Sigbjorn Finne -
Simon Marlow