createProcess shutting file handles
Hi, I want to run multiple programs and dump the stdout/stderr to a file, I've tried doing: h <- openFile file WriteMode let c = CreateProcess (RawCommand file []) Nothing Nothing Inherit (UseHandle h) (UseHandle h) False (_,_,_,pid) <- createProcess c waitForProcess pid hPutStrLn h "Test" But by the time I get to the hPutStrLn line it says: Main: test.log: hPutStr: illegal operation (handle is closed) What have I done wrong? Did createProcess close the handle, and is there a way round this? This is using GHC 6.10 on Windows with the new process-1.0.1.1 Thanks Neil
Hello, As far as I can tell, createProcess is closing the handle: createProcess :: CreateProcess -> IO (Maybe Handle, Maybe Handle, Maybe Handle, ProcessHandle) createProcess cp = do r <- runGenProcess_ "runGenProcess" cp Nothing Nothing maybeCloseStd (std_in cp) maybeCloseStd (std_out cp) maybeCloseStd (std_err cp) return r where maybeCloseStd :: StdStream -> IO () maybeCloseStd (UseHandle hdl) | hdl /= stdin && hdl /= stdout && hdl /= stderr = hClose hdl maybeCloseStd _ = return () I don't see a way around it. - jeremy At Fri, 13 Feb 2009 15:38:32 +0000, Neil Mitchell wrote:
Hi,
I want to run multiple programs and dump the stdout/stderr to a file, I've tried doing:
h <- openFile file WriteMode let c = CreateProcess (RawCommand file []) Nothing Nothing Inherit (UseHandle h) (UseHandle h) False (_,_,_,pid) <- createProcess c waitForProcess pid hPutStrLn h "Test"
But by the time I get to the hPutStrLn line it says:
Main: test.log: hPutStr: illegal operation (handle is closed)
What have I done wrong? Did createProcess close the handle, and is there a way round this? This is using GHC 6.10 on Windows with the new process-1.0.1.1
Thanks
Neil _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Fri, 2009-02-13 at 15:38 +0000, Neil Mitchell wrote:
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. I'm not exactly sure what the justification is. I thought at first it might be for the H98 many readers or single writer rule, but it's not obvious how that applies here. Duncan
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. Thanks Neil
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. Duncan
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 (4)
-
Duncan Coutts -
Jeremy Shaw -
Neil Mitchell -
Simon Marlow