Re: clone() <-> getpid() bug in 2.6?

Linus Torvalds
2004-06-05T23:18:31Z

On Sat, 5 Jun 2004, Davide Libenzi wrote:
>
> It is likely used by pthread_self(), that is pretty much performance
> sensitive. I'd agree with Ulrich here.

It _can't_ be used for pthread_self(), since the pid is the _same_ across
all threads in a pthread environment.

See?

I re-iterate:

- getpid() was used in some historical threading packages (maybe even
LinuxThreads) to get the thread ID thing.

But this particular usage requires the old Linux behaviour of returning
separate threads ID's for separate threads. CLONE_THREAD does not do
that, and in particular the glibc caching _breaks_ any such attempt
even when you don't use CLONE_THREAD.

pthreads() in modern libc sets CLONE_THREAD and then uses the
per-thread segment thing to identify threads. No getpid() anywhere.

Ergo: getpid() caching may result in faster execution, but in this case
it's actively _wrong_, and breaks the app. It's easy to make things go
fast if you don't actually care about whether the end result is correct
or not.

- getpid() is used in some silly benchmarks.

But in this case caching getpid() just lies to the benchmark, and is
pointless.

Ergo: getpid() caching results in higher scores, but the scores are now
meaningless, since they have nothing to do with system call speed any
more.

So in both of these cases, the caching literally results in WRONG
behaviour.

Can somebody actually find an application that doesn't fall into either of
the above two categories, and calls getpid() more than a handful of times?

Linus