[Haskell-cafe] createProcess shutting file handles

[Neil Mitchell]

>>>>> 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