[Haskell-cafe] createProcess shutting file handles
ndmitchell at gmail.com
Mon Feb 16 08:53:21 EST 2009
>>>>> 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 Handle,
> There's nothing stopping you from re-opening the file and seeking to the
> end, as a workaround.
"openFile file AppendMode" is how I ended up doing it, which saves
writing a seek in there. It works just fine, merely at the cost of
closing/opening handles more than necessary.
> 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 forgetting
Documenting it more clearly would be helpful. As for changing the
behaviour - while I think the other way round would be much better, it
brings up loads of reverse compatibility headaches, so I'm not sure
its worth it.
More information about the Haskell-Cafe