[Haskell-cafe] createProcess shutting file handles

Neil Mitchell 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
>> doubt!)
>
> 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,
> FWIW.
>
> 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
> something!

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.

Thanks

Neil


More information about the Haskell-Cafe mailing list