From: Peter Zijlstra <peterz@infradead.org>
To: mtk.manpages@gmail.com
Cc: Mike Galbraith <efault@gmx.de>,
Thomas Pilarski <thomas.pi@arcor.de>,
Andrew Morton <akpm@linux-foundation.org>,
Gregory Haskins <ghaskins@novell.com>,
bugme-daemon@bugzilla.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [Bugme-new] [Bug 12562] New: High overhead while switching or synchronizing threads on different cores
Date: Mon, 02 Feb 2009 19:35:14 +0100 [thread overview]
Message-ID: <1233599714.4787.221.camel@laptop> (raw)
In-Reply-To: <cfd18e0f0902021029q6ccc5bd1q291582525ca54a2b@mail.gmail.com>
On Tue, 2009-02-03 at 07:29 +1300, Michael Kerrisk wrote:
> Hi Peter,
>
> On Tue, Feb 3, 2009 at 1:15 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Mon, 2009-02-02 at 09:55 +0100, Peter Zijlstra wrote:
> >
> >> Ah, that was a good clue, apparently all you need to so it use
> >> random_r() and provide your own state and all should be well.
> >
> > Michael, would it make sense to add the random_r() family to the "SEE
> > ALSO" section of the random() man page?
> >
> > (Admittedly, my random() manpage is ancient: 2008-03-07, so it might be
> > this is already the case, in which case, ignore me :)
>
> (Up-to-date version of the pages can always be found online at the
> location in the .sig.)
Ah, I'll try to remember that.
> Well, the man page already had this text under notes:
>
> This function should not be used in cases where multiple
> threads use random() and the behavior should be reproducible.
> Use random_r(3) for that purpose.
Yeah, but I found it eventually, but I generally don't read a full
manpage when I'm looking for related functions, only the SEE ALSO
section.
> But it certainly doesn't hurt to have random_r(3) also listed under
> the SEE ALSO, and I've added it for man-pages-3.18.
Thanks.
next prev parent reply other threads:[~2009-02-02 18:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-12562-10286@http.bugzilla.kernel.org/>
2009-01-28 20:56 ` [Bugme-new] [Bug 12562] New: High overhead while switching or synchronizing threads on different cores Andrew Morton
2009-01-28 22:15 ` Peter Zijlstra
2009-01-28 22:25 ` Thomas Pilarski
2009-01-29 9:07 ` Peter Zijlstra
2009-01-29 10:12 ` Thomas Pilarski
2009-01-29 10:24 ` Thomas Pilarski
2009-01-29 10:31 ` Peter Zijlstra
2009-01-29 11:37 ` Peter Zijlstra
2009-01-29 14:05 ` Thomas Pilarski
2009-01-30 7:57 ` Mike Galbraith
2009-02-02 7:43 ` Thomas Pilarski
2009-02-02 8:19 ` Peter Zijlstra
2009-02-02 8:33 ` Thomas Pilarski
2009-02-02 8:52 ` Mike Galbraith
2009-02-02 8:55 ` Peter Zijlstra
2009-02-02 12:15 ` Peter Zijlstra
2009-02-02 18:29 ` Michael Kerrisk
2009-02-02 18:35 ` Peter Zijlstra [this message]
2009-02-03 4:55 ` Mike Galbraith
2009-02-03 3:56 ` Valdis.Kletnieks
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=1233599714.4787.221.camel@laptop \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=bugme-daemon@bugzilla.kernel.org \
--cc=efault@gmx.de \
--cc=ghaskins@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=thomas.pi@arcor.de \
/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.