Date:Fri, 14 Aug 2020 20:01:18 +0200
From:Edgar =?iso-8859-1?B?RnXf?=
Message-ID: <20200814180117.gq61...@trav.math.uni-bonn.de>
| 3. I don't see where POSIX defines or allows this, but given 2., I'm surely
|missing something.
Actually, I did go take a
Date:Fri, 14 Aug 2020 20:01:18 +0200
From:Edgar =?iso-8859-1?B?RnXf?=
Message-ID: <20200814180117.gq61...@trav.math.uni-bonn.de>
| 3. I don't see where POSIX defines or allows this, but given 2., I'm surely
|missing something.
It is specified to work this
> What I observe is that a process that explicitly ignores SIGCHLD
> (SIG_IGN), then forks a child which exits, when wait()ing for the
> child, gets ECHILD (i.e., wait returns -1 and errno is ECHILD).
And the ECHILD return is delayed until all children have terminated
(ie, until there are no
hello. I think Mouse said it best. There is a difference between
SIG_DFL and SIG_IGN, which is how you can not get signaled when a child
exists, but wait(2) will still wait for a child if you call it.
Hope that helps.
-Brian
On Aug 14, 10:10am, Brian Buhrow wrote:
} Subject: Re:
1. Sample program attached. Change SIG_IGN to SIG_DFL to see the difference.
2. macOS seems to behave the same way, as does Linux.
3. I don't see where POSIX defines or allows this, but given 2., I'm surely
missing something.
4. The wording in wait(2) could be improved to clarify this is
> I'm not sure I've completely understood your question
Probably not. Or I don't get what you are trying to say.
What I observe is that a process that explicitly ignores SIGCHLD (SIG_IGN),
then forks a child which exits, when wait()ing for the child, gets ECHILD
(i.e., wait returns -1 and errno
Hello. I'm not sure I've completely understood your question, but I
think you're confusing the issue of whether a child posts a SIGCHLD signal
when it exits versus whether the current process that's calling wait(2)
receives a SIGCHLD when a child exits. The default behavior, as I
The second question (that I forgot in the original mail) is whether
wait(2) returning ECHILD for whatwever handling of SIGCHLD is covered by POSIX.
> So does the
> because the calling process has asked the system
> to discard such status by ignoring the signal SIGCHLD
> mean that explicitly ignoring SIGCHLD is different from ignoring it
> per default?
I wouldn't say it *means* that, exactly, but I do think that this is a
case
I agree that this is confusing. While the system definitely
differentiates between SIG_DFL and SIG_IGN, the difference would
normally not be something I expected to make a difference in something
described the way wait(2) is documented.
I haven't really bothered going down into the code and
I'm confused regarding the behaviour of wait(2) wrt. SIGCHLD handling.
The wait(2) manpage says:
wait() will fail and return immediately if:
[ECHILD]The calling process has no existing unwaited-for child
processes; or no status from the terminated
11 matches
Mail list logo