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