All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@tv-sign.ru>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu,
	akpm@linux-foundation.org, roland@redhat.com,
	Michael Kerrisk <mtk-manpages@gmx.net>
Subject: Re: [PATCH] fix handling of SIGCHILD from reaped child
Date: Tue, 20 Feb 2007 20:20:49 +0300	[thread overview]
Message-ID: <20070220172049.GA67@tv-sign.ru> (raw)
In-Reply-To: <20070221002526.c6b7edb0.kamezawa.hiroyu@jp.fujitsu.com>

On 02/21, KAMEZAWA Hiroyuki wrote:
>
> On Tue, 20 Feb 2007 17:22:57 +0300
> Oleg Nesterov <oleg@tv-sign.ru> wrote:
> 
> >
> > I'd suggest to make a separate function, but not complicate collect_signal().
> >
> okay. I'll try again if people admit me to go ahead.

Yes, it would be nice to know what maintainers think. This is a user visible
change, even if good.

> > > +		clear_stale_sigchild(current, retval);
> > 
> > But we are not checking that SIGCHLD is blocked?
> > 
> I'm sorry if I don't read SUSv3 correctly. SUSv3 doesn't define how we should
> do if SIGCHLD is not blocked.(so I don't check not-blocked case.)

Probably it is me who misunderstands SUSv3. Could you point me the reference
to authoritative document? My understanding: if blocked AND wait() succeeds.

> IMHO, user's sig-child-handler is tend to call wait()/waitpid() and expects
> successful return. So removing stale signal here may be good.

Yes. But sig-child-handler should do

	while (wait() >= 0)
		....

anyway, because SIGCHLD is not a realtime signal.

> If this breaks assumptions of applications on Linux, I'll not go eagerly.

I just don't know... (Michael Kerrisk cc'ed).

Oleg.


  reply	other threads:[~2007-02-20 17:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-20  9:32 [PATCH] fix handling of SIGCHILD from reaped child KAMEZAWA Hiroyuki
2007-02-20 14:22 ` Oleg Nesterov
2007-02-20 15:25   ` KAMEZAWA Hiroyuki
2007-02-20 17:20     ` Oleg Nesterov [this message]
2007-02-20 23:10       ` Roland McGrath
2007-02-21  0:51         ` KAMEZAWA Hiroyuki
2007-02-21  0:42       ` KAMEZAWA Hiroyuki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070220172049.GA67@tv-sign.ru \
    --to=oleg@tv-sign.ru \
    --cc=akpm@linux-foundation.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mtk-manpages@gmx.net \
    --cc=roland@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.