[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.00.0909120032270.31018@swampdragon.chaosbits.net>
Date: Sat, 12 Sep 2009 00:40:55 +0200 (CEST)
From: Jesper Juhl <jj@...osbits.net>
To: Ingo Molnar <mingo@...e.hu>
cc: Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Mike Galbraith <efault@....de>
Subject: Re: [GIT PULL] sched/core for v2.6.32
[...]
> Highlights:
>
> - Child-runs-first is now off - i.e. we run parent first.
> [ Warning: this might trigger races in user-space. ]
[...]
Ouch. Do we dare do that?
vfork() is supposed to always run the child first.
Most people I've talked to over the years assume that using fork(), the
child runs first (yes, I know, that's not guaranteed, but people have come
to believe that it is so and some may even depend on it).
I must admit that I do not have the understanding of the code needed to
see why this is done, I'm just scared that this may cause lots of problems
for userspace programs that (for whatever reason) have come to rely on
child-runs-first semantics.
I assume there's a very good reason to do this, I'm just not sure we want
to do it regardless of what (I assume) performance bennefits it brings.
Will userspace apps really bennefit from this (In the real world, not in
some fantasy world where everyone reads standards and do things then
"proper" way)?
--
Jesper Juhl <jj@...osbits.net> http://www.chaosbits.net/
Plain text mails only, please http://www.expita.com/nomime.html
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
--
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