> That's a threads package problem. Our numbers agree nicely on the 3.5
> usecs time - I get 1.75 usecs for a 2 process context switch plus about
> 2.7 usecs for overhead of passing a word through pipes. So if the glibc
> is getting 20 usecs or so, they are busted. But that has nothing to do
> with our discussion here: my claim is that if the process performance is
> good enough, the whole need for threads as a concept goes a way - a thread
> is just a different set of attributes on the process, i.e., shared VM,
> signals, PWD, whatever. And I'm assuming that you are happy with the
> 3 usecs number and that's about the same as the process number. So where's
> the need for threads?
Hmm. I know it's not really related to linux-kernel but still... WHY glibc is
getting 20 usecs or so and can it be shrinked down to 3 usecs ? Usually peoples
(like Apache developers, for examle) do not use clone(), it uses pthreads:
clone is nice and all but it's non-portable...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/