Re: Again: Runtime system doesn't notice changed file descriptor status

Hello.

I've had the misconception that a file descriptor can be in a closed state. So 
the bug report was rather misguided - sorry for that. 

Yes, what I actually want is to reset the stdin handle. Thanks for the hint to 
hDuplicateTo. This should be exactly what I need.

I see that the thing which the file descriptor is connected to can be in an 
EOF state (end of file, other side of pipe closed...), whereas the file 
descriptor is still valid. This means that the Haskell Library Report 
actually demands for a closedness state to be maintained in the file handle, 
since EOF and closed handle are two different things (result in different 
exceptions etc).

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.

Greetings,
Volker

-- 
http://www.volker-wysk.de