On Tue, Apr 6, 2021 at 10:54 AM L A Walsh <b...@tlinx.org> wrote: > > > On 2021/04/06 00:23, Oğuz wrote: > > 5 Nisan 2021 Pazartesi tarihinde L A Walsh <b...@tlinx.org > > <mailto:b...@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. >
I have no idea what you're talking about. See my first post, I demonstrated the behavior that I think should be changed there.
