>>>>> 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
