Messages in this thread | | | Date | Sat, 5 Jun 2004 14:13:12 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: clone() <-> getpid() bug in 2.6? |
| |
On Sat, 5 Jun 2004, Arjan van de Ven wrote: > > ... or glibc internally caches the getpid() result and doesn't notice the > app calls clone() internally... strace seems to show 1 getpid() call total > not 2.
Why the hell does glibc do that totally useless optimization?
It's a classic "optimize for benchmarks" thing - evil. I don't see any real app caring, and clearly apps _do_ fail when you get it wrong, as shown by Russell.
And it's really easy to get it wrong. You can't just invalidate the cache when you see a "clone()" - you have to make sure that you never ever cache it ever after either.
Uli, if Arjan is right, then please fix this. It's a buggy and pointless optimization. Anybody who optimizes purely for benchmarks should be ashamed of themselves.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |