Again: Runtime system doesn't notice changed file descriptor
status
Simon Marlow
simonmar at microsoft.com
Thu Jan 20 04:18:14 EST 2005
On 20 January 2005 00:49, Volker Wysk wrote:
> However, I'd still expect "hClose stdin" to actually close the file
> descriptor. I've taken a look at the hClose implementation. It's
> problematic not to actually close any standard file descriptors. For
> instance, some process might be reading the standard output of a
> Haskell program. When that program calls "hClose stdout", the
> process' read will block, rather than succeed with zero bytes read
> (EOF). The process won't notice that the program has finished
> outputting, until the program terminates. Imagine a case where a
> program outputs some status messages and then forks into demon mode,
> closing its standard file descriptors in order to detach itself from
> the terminal. I'm wondering if there's any particular reason for not
> actually closing the standard file descriptors.
I see your point. I don't know why hClose doesn't actually close the
std file descriptors - that bit of code was inherited from the previous
incarnation of the IO library.
Unless anyone can think of a good reason why not, I'll remove that
restriction and make hClose work on stdin, stdout, and stderr. Be
careful not to do this under GHCi, though!
Cheers,
Simon
More information about the Glasgow-haskell-bugs
mailing list