Re: [Haskell-cafe] createProcess shutting file handles
On Sun, 2009-02-15 at 11:06 +0000, Duncan Coutts wrote:
On Sun, 2009-02-15 at 09:24 +0000, Neil Mitchell wrote:
Hi
What have I done wrong? Did createProcess close the handle, and is there a way round this?
The docs for runProcess says:
Any Handles passed to runProcess are placed immediately in the closed state.
but the equivalent seems to be missing from the documentation for createProcess.
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. Duncan
Hi
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!) Thanks Neil
Neil Mitchell wrote:
Hi
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. 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! Cheers, Simon
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
participants (3)
-
Duncan Coutts -
Neil Mitchell -
Simon Marlow