[lkml]   [2004]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Using getpid() often, another way? [was Re: clone() <-> getpid() bug in 2.6?]

On Sun, 6 Jun 2004, Russell Leighton wrote:
> Linus said he could not imagine a program using getpid() more than a
> handful of times...

No, I said that I could not imagine using it more than a handful of times
_except_ for the cases of:

- thread identification without a native thread area
- benchmarking.

(and in both of these cases it is _wrong_ to cache the pid value)

> well, (I am ashamed to admit it) I found this getpid() bug with just
> such a program.
> Could someone can suggest an alternative to using getpid() for me?
> Here's the problem...
> I have a library that creates 2 threads using clone().

Your problem falls under the thread ID thing. It's fine and understandable
to use getpid() for that, although you could probably do it faster if you
are willing to use the support that modern kernels give you and that glibc
uses: the "TLS" aka Thread Local Storage support.

Thread-local storage involved having a user-mode register that points some
way to a special part of the address space. On x86, where the general
register set is very limited and stealing a general reg would thus be bad,
it uses a segment and loads the TLS pointer into a segment register
(segment registers are registers too - and since nobody sane uses them for
anything else these days, both %gs and %fs are freely usable).

> Would gettid() be any better?

You'd avoid this particular glibc bug with gettid.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-11-18 23:46    [W:0.078 / U:1.524 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site