From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds To: C H Forsyth Cc: 9fans@cse.psu.edu Subject: Re: [9fans] Re: Threads: Sewing badges of honor onto a Kernel In-Reply-To: <749601c045a56e4f77835f30907e255b@vitanuova.com> Message-ID: References: <749601c045a56e4f77835f30907e255b@vitanuova.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Fri, 27 Feb 2004 09:43:47 -0800 Topicbox-Message-UUID: 005996bc-eacd-11e9-9e20-41e7f4b1d025 On Fri, 27 Feb 2004, C H Forsyth wrote: > > my impression, and it's only that, is that relatively few user mode > applications use clone-for-threads at all on Linux, as yet. No, there's tons of them. But they almost always use the pthreads interfaces. Few applications use "clone()" directly, since there is seldom any point to going to that low level. So libc does a mapping (pretty trivial these days thanks to the new signal interfaces) of pthreads to clone() and other low-level kernel functionality. There's a lot more to threads than just creating them, btw. Linux has a whole "futex" infrastructure for doing fast user-level mutual exclusion (which in a pthreads world get mapped to pthread_mutex calls etc). Again, the kernel interfaces are _not_ the pthreads interfaces (since it would be crazy to call into the kernel just for a simple lock - 99.99% of the time you can do it with a simple atomic sequence in user space). But they are there to support _any_ kind of thread synchronization, whether pthreads- based or anything else. Linus