[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABe66sWwvCq=vWq5=ojbgHZeG764BGvts0cMJExTVrTeHRS+KA@mail.gmail.com>
Date: Fri, 1 Jun 2012 16:00:15 -0400
From: Filipe Brandenburger <filbranden@...il.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Tejun Heo <tj@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
David Rientjes <rientjes@...gle.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] prctl: pdeath_signal sent when parent thread (instead
of parent process) dies
Hi Oleg,
On Fri, Jun 1, 2012 at 3:02 PM, Oleg Nesterov <oleg@...hat.com> wrote:
> Filipe, you can't even imagine how much do I like this change
> personally ;) Although I think that pdeath_signal code should
> be moved into reparent_leader(). I suggested this many times.
Yes, that would really make sense!
> But I was told there are users which depend on current behaviour,
> they really want to know when the parent _thread_ exits.
Hmmm... but is it the parent thread inside the same process or the
thread of the parent process that forked it?
The former would kind of make sense to me, even though I would
probably implement it through another "option" parameter such as
PR_SET_TDEATHSIG or similar... the latter, doesn't really make any
sense to me...
> Why? I have no idea. And I agree this is ugly, but we can't
> break user-space.
At the very least, then, I think the man page for prctl(2) needs to be
updated, since PR_SET_PDEATHSIG and PR_GET_PDEATHSIG both refer
literally to the parent process.
Cheers,
Filipe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists