Re: [PATCH 1/7] cpu-timers: high-resolution CPU clocks for POSIX clock_* syscalls

[Linus Torvalds <torvalds@osdl.org>]

On Tue, 14 Dec 2004, Roland McGrath wrote:
>
> I believe Christoph may have been referring exclusively to the per-process
> clocks, not the per-thread clocks.

Please do not confuse things.

There still are no such things as "threads" vs "processes" as far as the 
kernel is concerned.

They are all the same thing, and they are all threads or processes or
whatever you want to call them. I've tried to call them "contexts of
execution" just to clarify the fact that they are _not_ threads of
processes. And they all have a unified ID space.

They just happen to share different things. We should try to avoid at all
cost to take on stupidities from legacy systems. We've got a unified
process/thread/whatever space, and that's a good thing.

Yes, when you share the signal state (and you have to share the VM and
signal handlers to do so), you end up looking like a pthreads "process".
But dammit, people should NOT think that that is all that special from a
kernel standpoint.

And no kernel interface should really care about some pthreads rules. The 
interfaces should work with old linux-threads, and with pure "clone()" 
things too.

Of course, in this case, it's doubtful whether we want to expose non-local
clocks to anybody else, making the whole point pretty moot. I'd vote for
not exposing them any more than necessary (ie the current incidental "ps"  
interface is quite enough), at least until somebody can come up with a
very powerful example of why exposing them is a good idea.

		Linus