>>> but isn't what's supposed to happen when a child's parent is
>>> ignoring SIGCHLD - the child should skip zombie state, and simply
>>> be cleaned up.
>> And how is "reparent to init" not an acceptable means of
>> implementing that?
> Acceptable or not, it would seem to not match our own
On 2020-08-16 21:17, Mouse wrote:
They don't vanish, they get reparented to init(8) which then wakes
up and reaps them.
That probably would work, approximately,
Well, it does work, to at least a first approximation.
but isn't what's supposed to happen when a child's parent is ignoring
>> I don't understand what problem queued SIGCHLD was invented to
>> address.
> My impression is that it allows you to get notified of state changes
> of your child processes. If one signal could annonce several state
> changes, how would you know what these state changes are?
You'd call
> I don't understand what problem queued SIGCHLD was invented to address.
My impression is that it allows you to get notified of state changes of your
child processes. If one signal could annonce several state changes, how
would you know what these state changes are?
>> They don't vanish, they get reparented to init(8) which then wakes
>> up and reaps them.
> That probably would work, approximately,
Well, it does work, to at least a first approximation.
> but isn't what's supposed to happen when a child's parent is ignoring
> SIGCHLD - the child should skip
In article <28808.1597602...@jinx.noi.kre.to>,
Robert Elz wrote:
>Date:Sun, 16 Aug 2020 16:13:57 - (UTC)
>From:chris...@astron.com (Christos Zoulas)
>Message-ID:
>
> | They don't vanish, they get reparented to init(8) which then wakes up
> | and reaps them.
>
Date:Sun, 16 Aug 2020 16:13:57 - (UTC)
From:chris...@astron.com (Christos Zoulas)
Message-ID:
| They don't vanish, they get reparented to init(8) which then wakes up
| and reaps them.
That probably would work, approximately, but isn't what's supposed to
In article <5919.1597441...@jinx.noi.kre.to>,
Robert Elz wrote:
>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
> On Aug 16, 2020, at 5:58 AM, Robert Swindells wrote:
>
>
> Taylor R Campbell wrote:
>>> Date: Sat, 15 Aug 2020 19:59:24 +0100
>>> From: Robert Swindells
>>>
>>> Is anyone working on the proposed solution to kern/55230 ?
>>
>> thorpej was working on it and has a patch -- I thought it got
Taylor R Campbell wrote:
>> Date: Sat, 15 Aug 2020 19:59:24 +0100
>> From: Robert Swindells
>>
>> Is anyone working on the proposed solution to kern/55230 ?
>
>thorpej was working on it and has a patch -- I thought it got
>committed, but I guess not? There might have been some hard-to-fix
>>> When I install a SIGCHLD handler via sigaction() using SA_SIGINFO,
>>> is it guaranteed that my handler is called (at least) once per
>>> death-of-a-child?
>> "Maybe." It depends on how portable you want to be.
>> [...]
> While we're on this topic. Unix signals don't exactly work like
>
On 2020-08-16 12:49, Johnny Billquist wrote:
On 2020-08-15 22:46, Mouse wrote:
When I install a SIGCHLD handler via sigaction() using SA_SIGINFO, is
it guaranteed that my handler is called (at least) once per
death-of-a-child?
"Maybe." It depends on how portable you want to be.
On 2020-08-15 22:46, Mouse wrote:
When I install a SIGCHLD handler via sigaction() using SA_SIGINFO, is
it guaranteed that my handler is called (at least) once per
death-of-a-child?
"Maybe." It depends on how portable you want to be.
Historically, "no": in some older systems, a second
Jason Thorpe writes:
> From my reading of the code, it seems that there are no longer any
> circumstances where pmap_activate() will be called with non-curlwp, at
> least in MI code.
>
> Is this a correct reading?
seems right, and only vax has one MD caller that appears to
not be curlwp but
14 matches
Mail list logo
