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.
