On 2004-10-26, Peter Simons wrote:

John Goerzen writes:

...

(progname): forkProcess: uncaught exception

Quoting from the documentation:

forkProcess :: IO () -> IO ProcessID

[...] On success, forkProcess returns the child's ProcessID to the parent process; in case of an error, an exception is thrown.

What I assume is happening is this: The child terminates _right away_, with a non-success error code, no less. And my guess is that forkProcess interprets this as the /fork/ having failed and throws an exception.

If you follow this a little bit, you'll find that forkProcess is *NOT* throwing the exception that is being reported here. The message is being printed by the RTS of the child process. No exception is thrown in the parent. (Believe me, I've tried to catch it!) I thought about that a bit, and realized that is the only way it could be; there's no way an exception could propogate from a child forked process to the parent. In my particular case, in my child process, the problem was occuring when I detected an exec failure and wnated to terminate with an error code for the parent to catch. I called dupTo a few times in the child before that, so while it failed fast, it was doing things.

The following program, for example, works fine:

...

import System.Exit import System.Posix.Process import Control.Concurrent main = forkProcess (threadDelay (10*1000000) >> exitFailure)

I have no idea why that would be. Sigh.

Peter

-- John Goerzen Author, Foundations of Python Network Programming http://www.amazon.com/exec/obidos/tg/detail/-/1590593715

On 2004-10-26, Peter Simons wrote:

just to avoid any possible confusion: I emailed my reply to you and posted it to the list as well, but unfortunately I hit the wrong button so that my mail to you doesn't _say_ that it is a carbon copy. Sorry about the mess.

OK, thanks.

By the way: It's good to know I'm not the only one wrestling with Haskell's concurrency code. :-)

Yes. Its POSIX interface is, uhm, weird. I can't quite put my finger on it, but things like setting up a pipe to a child process's stdin just seem brittle and fragile with all sorts of weird errors. I can do this in my sleep in C, Perl, or Python but in Haskell I can barely make it work when I'm fully conscious :-) Oh also, I would very much appreciate Haskell interfaces to realpath() and readlink(). And a system/rawSystem that returns the waitpid() exit status like system(3) does, not just the exit code. (What happens if the process died because of a signal?) -- John

John Goerzen wrote:

Oh also, I would very much appreciate Haskell interfaces to realpath() and readlink().

I don't know about realpath() (which is a BSD-ism, and included in GNU libc, but I'm not sure about other Unices), but readlink() exists as System.Posix.readSymbolicLink. -- Glynn Clements

On Wed, Oct 27, 2004 at 11:30:12AM +0100, Simon Marlow wrote:

The System.Posix library is severely lacking in documentation. Ideally for each function it would list the POSIX equivalent, and a table with the mapping in the other direction would be useful too.

One idea on this topic: Many POSIX wrappers, eg getProcessStatus[1], take mysterious Boolean arguments. I commonly create a new type when I have a function like this, so it might be data Blocking = Blocking | NonBlocking data IncludeStopped = IncludeStopped | ExcludeStopped getProcessStatus :: Blocking -> IncludeStopped -> ProcessID -> IO (Maybe ProcessStatus) Would this make these functions easier to use, or would it just be an additional annoyance to have to look up the values of these type? (I may have picked an extreme example, because even someone who knows POSIX by heart couldn't be sure which Boolean is which!) Andrew [1] http://haskell.org/ghc/docs/latest/html/libraries/unix/System.Posix.Process....

Simon Marlow wrote:

...

Yes. Its POSIX interface is, uhm, weird. I can't quite put my finger on it, but things like setting up a pipe to a child process's stdin just seem brittle and fragile with all sorts of weird errors. I can do this in my sleep in C, Perl, or Python but in Haskell I can barely make it work when I'm fully conscious :-)

*laughs*

Is there anything concrete we can do? The POSIX layer is supposed to be pretty minimal, so in theory most POSIX idioms should not be harder in Haskell, and hopefully should be easier.

Part of the problem is that you can't always consider the use of individual POSIX functions in isolation. Things which are done (possibly unknowingly) in one place might affect the way in which other system calls behave. 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. 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). 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. -- Glynn Clements

John Goerzen writes:

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().

On Linux it duplicates unflushed output (hmm, I thought they fixed this a few years ago). X/Open specification doesn't say anything about this. #include #include int main() { printf("1 "); fflush(stdout); printf("2 "); fork(); printf("3\n"); } Output: 1 2 3 2 3 In C you cay say fflush(NULL) to flush all open output streams. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/