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

[Linus Torvalds <torvalds@osdl.org>]

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