On Saturday 22 September 2007 16:35:56 Andreas Schwab wrote:
> "John Z. Bohach" <[EMAIL PROTECTED]> writes:
> > if (WIFEXITED(siginfo->si_status))
>
> That does not make any sense. si_status is _not_ a wait status.
>
> Andreas.
Thank you for clearing that up. That explains it.
--john
-
To
"John Z. Bohach" <[EMAIL PROTECTED]> writes:
> if (WIFEXITED(siginfo->si_status))
That does not make any sense. si_status is _not_ a wait status.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key
On Saturday 22 September 2007 11:49:09 Michael Kerrisk wrote:
> John,
>
...snip...
>
> If the child terminated by calling exit(), regardless of whether it
> was done from inside a signal handler, then WIFEXITED() should test
> true, but WIFSIGNALED() will not. If you are seeing otherwise, then
On Sat, 2007-09-22 at 11:22 -0700, John Z. Bohach wrote:
> Hello,
>
> It is unclear from the various documentions in the kernel and glibc what
> the proper behaviour should be for the case when a child process
> catches a SIGNAL (say for instance, SIGTERM), and then calls exit()
> from within
John,
> It is unclear from the various documentions in the kernel and glibc what
> the proper behaviour should be for the case when a child process
> catches a SIGNAL (say for instance, SIGTERM), and then calls exit()
> from within its caught SIGNAL handler.
>
> Since the exit() will cause a
Hello,
It is unclear from the various documentions in the kernel and glibc what
the proper behaviour should be for the case when a child process
catches a SIGNAL (say for instance, SIGTERM), and then calls exit()
from within its caught SIGNAL handler.
Since the exit() will cause a SIGCHLD to
Hello,
It is unclear from the various documentions in the kernel and glibc what
the proper behaviour should be for the case when a child process
catches a SIGNAL (say for instance, SIGTERM), and then calls exit()
from within its caught SIGNAL handler.
Since the exit() will cause a SIGCHLD to
John,
It is unclear from the various documentions in the kernel and glibc what
the proper behaviour should be for the case when a child process
catches a SIGNAL (say for instance, SIGTERM), and then calls exit()
from within its caught SIGNAL handler.
Since the exit() will cause a SIGCHLD to
On Sat, 2007-09-22 at 11:22 -0700, John Z. Bohach wrote:
Hello,
It is unclear from the various documentions in the kernel and glibc what
the proper behaviour should be for the case when a child process
catches a SIGNAL (say for instance, SIGTERM), and then calls exit()
from within its
On Saturday 22 September 2007 11:49:09 Michael Kerrisk wrote:
John,
...snip...
If the child terminated by calling exit(), regardless of whether it
was done from inside a signal handler, then WIFEXITED() should test
true, but WIFSIGNALED() will not. If you are seeing otherwise, then
show
John Z. Bohach [EMAIL PROTECTED] writes:
if (WIFEXITED(siginfo-si_status))
That does not make any sense. si_status is _not_ a wait status.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint =
On Saturday 22 September 2007 16:35:56 Andreas Schwab wrote:
John Z. Bohach [EMAIL PROTECTED] writes:
if (WIFEXITED(siginfo-si_status))
That does not make any sense. si_status is _not_ a wait status.
Andreas.
Thank you for clearing that up. That explains it.
--john
-
To unsubscribe
12 matches
Mail list logo
