[Haskell-cafe] createProcess shutting file handles
marlowsd at gmail.com
Mon Feb 16 07:50:57 EST 2009
Neil Mitchell wrote:
>>>> However the createProcess command structure has the close_fds flag,
>>>> which seems like it should override that behaviour, and therefore this
>>>> seems like a bug in createProcess.
>>> close_fds :: Bool
>>> Close all file descriptors except stdin, stdout and stderr in
>>> the new process
>>> This refers to inheriting open unix file descriptors (or Win32 HANDLEs)
>>> in the child process. It's not the same as closing the Haskell98 Handles
>>> in the parent process that you pass to the child process.
>> So lets not talk about if the current behaviour is a bug or not. It's
>> reasonably clear (if not brilliantly well documented) that it's the
>> intended behaviour.
>> The thing we want to talk about is what reason is there for the current
>> behaviour, if that's necessary and if it is the sensible default
>> behaviour. As I said before I don't know why it is the way it is. I'm
>> cc'ing the ghc users list in the hope that someone there might know.
> One guiding principle of resource management is that whoever
> opens/allocates something should release/free it. i.e. if you did the
> malloc you do the free. For that reason it seems weird that I call
> openFile but someone else calls hClose on my behalf.
> Plus, in my particular application, the above behaviour is necessary
> or I'm going to have to write to a file, open that file, and copy it
> over to my intended file (which is what I will end up doing, no
I don't remember exactly why it's done this way, but it might have
something to do with trying to maintain the (possibly ill-conceived)
Haskell98 file-locking principle. System.Posix.handleToFd also closes the
There's nothing stopping you from re-opening the file and seeking to the
end, as a workaround.
I could probably be convinced without much difficulty that we should stop
closing these Handles; however I do have a vague feeling that I'm
More information about the Haskell-Cafe