|
From: | L A Walsh |
Subject: | Re: SIGCHLD traps shouldn't recurse |
Date: | Tue, 06 Apr 2021 00:54:20 -0700 |
User-agent: | Thunderbird 2.0.0.24 (Windows/20100228) |
On 2021/04/06 00:23, Oğuz wrote:
5 Nisan 2021 Pazartesi tarihinde L A Walsh <bash@tlinx.org <mailto:bash@tlinx.org>> yazdı:On 2021/04/03 00:41, Oğuz wrote: but I don't think it's useful at all because the number of pending traps keeps piling up, and there is no way to reset that number. If there is no real use case for recursive SIGCHLD traps (which I can't think of any), I think this should change; no SIGCHLD trap should be queued while a SIGCHLD trap is already in progress.
They have to be queued. Else how do you process their ending? It is something that take very little time. The parent is given the chance to collect child accounting info and the child's status. How long do you think that should take? Sigchld handlers do bookkeeping, not significant computation. Are you asking what happens if the application is misdesigned from the beginning to need more CPU than is available at a child's death? If that happens then the application needs to be fixed.
[Prev in Thread] | Current Thread | [Next in Thread] |