Re: Using getpid() often, another way? [was Re: clone() <-> getpid()bug in 2.6?]

[Linus Torvalds]

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.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/