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