[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1231613164.11642.108.camel@quest>
Date: Sat, 10 Jan 2009 18:46:04 +0000
From: Scott James Remnant <scott@...onical.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Casey Dahlin <cdahlin@...hat.com>,
Roland McGrath <roland@...hat.com>,
Ulrich Drepper <drepper@...il.com>,
Ingo Molnar <mingo@...e.hu>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Randy Dunlap <randy.dunlap@...cle.com>,
Davide Libenzi <davidel@...ilserver.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [RESEND][RFC PATCH v2] waitfd
On Sat, 2009-01-10 at 19:21 +0100, Oleg Nesterov wrote:
> On 01/10, Scott James Remnant wrote:
> >
> > On Sat, 2009-01-10 at 17:19 +0100, Oleg Nesterov wrote:
> >
> > > I am not sure we are talking about the same thing, but afaics poll() +
> > > signalfd can work to (say) reap the childs. Actually, ppoll() alone is
> > > enough.
> > >
> > Last time I checked, ppoll() was not actually implemented across all
> > architectures in a manner that solved the race it was intended to solve.
> >
>
> As I said, this is imho unfair. But I mentioned ppol() "just in case".
>
> My questiong was why do you think that "signalfd() can't currently be
> made to work in the way you describe". You have dropped this part to
> change the topic?
>
Sorry, I may not be following LKML etiquette correctly. These couple of
recent threads (other than some bugs I found in wait last year) are my
first real attempt to participate here.
I wasn't intending to "change the topic" or dropping the parts about
changing signalfd() to somehow sweet it under the carpet.
Rather than posting repeatedly across the thread, I tried to consolidate
my responses into the other post you've replied to.
You made an interesting point about ppoll here, so I only responded to
that to find out whether the situation of that syscall had been
improved.
Not so much changing the topic, but asking a side-bar question ;)
Scott
--
Scott James Remnant
scott@...onical.com
Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)
Powered by blists - more mailing lists