On Fri, 2004-01-09 at 20:58, Andy Bakun wrote: > On Thu, 2004-01-08 at 05:24, Chris Nolan wrote: > > > 3. Wait for a while. Linux 2.6 includes (as does the RedHat 9.0 and > > ES/WS/AS 3.0 kernels) NPTL - the Native POSIX Threads for Linux > > implementation which is superior in many ways and does not use clone() > > at all. As you'll no longer want to use clone() for threaded apps (trust > > me on this), I'm betting that all interested parties will start > > complaining in the relevant mailing lists. > > Chris, do you have some references for this? I'd love to read up on it > to find out what's coming. All references to NPTL I can find via google > as it relates to changes in 2.6 talk about how 2.6 has additional > clone() options that NPTL takes advantage of (most of them reference a > text that is available at http://kerneltrap.org/node/view/422). Also, > why are you down on clone() -- I trust you, but I want to learn! :) > My references come from the LKML and KernelTrap! :-) I'm a bit of a geek in this respect, and quite enjoy reading up on OS internals. If you have a look at Ulrich Drepper's home page (somewhere on Redhat's servers) he's got some info about the beast as he wrote NPTL. Admittedly, it almost seems as if he wrote it in response to NGPT (Next Generation POSIX Threads - a competing but now unsupported thread implementation for kernel 2.6 inclusion).
Regarding clone(), there's not a thing wrong with it. clone() produces what are essentially processes though. Given the low cost of context switches in Linux, this isn't a big issue for performance but in terms of POSIX compliance it is quite a large problem for the following reasons: * POSIX says that all threads should get the same return value upon executing getpid(). clone() does not allow this. * POSIX says that signals should be seen by all threads in a process. clone() does not allow this. * POSIX says quite a few things about cancellation points. LinuxThreads currently only has a few cancellation points (on about 2 pthread_ functions). Basically, all system calls that block should act as cancellation points. * clone() is subject to many of the same limitations as fork(). Performance is also similar. Thread creation and destruction are quite slow compared to the new implementation (although the various other kernel improvements have resulted in fork() having constant latency over number of calls while pthread_create() has a slight rise in latency after some ungodly number of calls. * Attempting to create thousands of threads is a real problem with LinuxThreads in terms of resource utilisation. NPTL doesn't have this problem. Most of the above shortcomings not mentioning clone() can be attributed at least paritally to clone()'s use. clone() does have some good uses though, if the existance of vfork() is to be considered just in the universe. Everyone, please pull me up on anything I've said here that sounds like tripe! Regards, Chris > -- > Andy Bakun <[EMAIL PROTECTED]> > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
