On 2004-10-27, Glynn Clements <[EMAIL PROTECTED]> wrote: > One major issue is the way in which fork() has global consequences. > > E.g. if a library has file descriptors for internal use, fork() will > duplicate them. If the library subsequently closes its copy of the > descriptor, but the inherited copy (which the child may not even know > exists) remains open, the file (socket, device, etc) will remain open.
This is not a novel problem with Haskell, but it certainly bears remembering. > Another example of this is the interaction between buffered streams > and descriptors. If a process forks while "unflushed" data remains in > a stream, the data may be written twice. This can be quite serious if > the stream corresponds to some form of control channel (i.e. a pipe or > socket communicating with another process). And this *is* a novel problem I hadn't thought of before. It's quite possible this has been causing some of my troubles. I would think that createProcess should automatically flush all open handles before it does the fork, and that it should probably be considered a bug if it doesn't. If it does, then the exec stuff should too. If it doesn't, then the exec stuff must not. (If the exec stuff did but forkProcess didn't, it would break the idiom of fork() then exec() that happens to work now because the exec() discards all those buffers.) I wonder what the behavior of fwrite() in this situation is. I don't know if it ever performs buffering such that write() is never called during a call to fwrite(). I also wonder if the forkIO and friends suffer from the same problem. > Ultimately, the only real solution to such issues is to ensure that > any high-level functionality provides a sufficient level of > cooperation with lower-level code, e.g. allowing it to be > "synchronised", or at least shut down into a state such that it > doesn't interfere, ensuring that it doesn't hide "unnecessary" details > which may actually be necessary in more involved programs, etc. Yup. -- John _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
