In local.glasgow-haskell-bugs, you wrote:
Am 10. Jul 2002 um 22:21 CEST schrieb Dean Herington:
The first issue I confronted is that the get*ProcessStatus routines return
an error rather than nothing if there is no candidate child process.
Yes, `waitpid' might return with EINTR which will
Volker Stolz wrote:
In local.glasgow-haskell-bugs, you wrote:
Am 10. Jul 2002 um 22:21 CEST schrieb Dean Herington:
The first issue I confronted is that the get*ProcessStatus routines return
an error rather than nothing if there is no candidate child process.
Yes, `waitpid' might
I had thought of having the signal handler reap as many
terminated child
processes as possible, but had been concerned about a possible race
condition. After you suggested that approach, I thought some more and
decided that no race problem should exist. So I've
implemented multiple
The fine points of Unix signal semantics have always been somewhat
mysterious to me. However, after digging around in man pages
for a while,
I have a theory as to what's going wrong...
Yes, your diagnosis looks very plausible.
The right way, I believe, to handle this in your signal
Simon Marlow wrote:
The fine points of Unix signal semantics have always been somewhat
mysterious to me. However, after digging around in man pages
for a while,
I have a theory as to what's going wrong...
Yes, your diagnosis looks very plausible.
The right way, I believe, to handle
I have some GHC-compiled programs that run OK under Sparc/Solaris but
hang under x86/Linux. I'm using GHC 5.02.3 on both systems (although
I've tried GHC 5.03.20020410 on Linux with the same failures). I'm
debugging to narrow the problem down. My current suspicion is that
closing the
After much study I have a new theory. It appears that the
pipe machinery
is working fine, but that sometimes my program fails to
reap all of its
terminated child processes. I'm using a `sigCHLD` signal handler that
does `getAnyProcessStatus True False` each time it's invoked.
It
