libkse to libpthread switch on FreeBSD 26
Dan writes "Daniel Eischen says that libkse has been renamed back to libpthread and is now the default threads library. The gcc-pthread option has also been changed to link to libpthread instead of libc_r. For alpha and sparc64 machines, libkse has not been renamed and links are installed so that libpthread points to libc_r. FreeBSD GNOME team's Joe Marcus Clarke confirmed that the ports system will switch to using libpthread as the default for PTHREAD_LIBS shortly. A patch set is currently being tested, once that completes, the necessary port hooks will be in place to easily build applications linked to libpthread."
BSD may be dying... (Score:4, Insightful)
I don't think for one minute that SCO's claims about Linux are legitimate, but imagine if they were: and some idiot judge ordered that Linux distribution was stopped. I think all the BSD trolls might be glad of an alternative kernel and userland under those circumstances!
Re:BSD may be dying... (Score:3, Interesting)
Linux is trying to "do a Windows" and be all things to all men as quickly as possible.
FreeBSD is more like a working pick-up truck. They don't have a wide range of paint colors and picking up chicks with them can be hard - but they do what they are built for, and they do it very well.
Re:BSD may be dying... (Score:2, Offtopic)
You mean staring at UFO's and conjugal relations with not-quite-second cousins?
Sorry. Someone had to say it - might as well be me.
More on point - if FreeBSD is dying - why is everyone so determined to point out that it is dying (which it isn't)? Wishful thinking?
Re:BSD may be dying... (Score:1, Offtopic)
I think that, these days, the "BSD is dying" posts are more a traditional thing to do on Slashdot than any sort of expression of fact or desire.
Re:BSD may be dying... (Score:2, Offtopic)
The trolls are probably a small number of people that have their own reasons that wouldn't make sense to us. As for the rest... I have a friend that thinks Linux will gradually force everything out because it's good enough at everything, rather than really good at any particular thing. He's not a zealot, but that's what he thinks. I think that's a common attitude.
(many) Linux supporters see the OS world as a tri
Re:BSD may be dying... (Score:2)
Ultimately I see it all but c
Re:BSD may be dying... (Score:1)
This statement doesn't make sense. It implies that there is one group taking an operating kernel and trying to stretch it out everywhere?
LOTS of people are trying to take various distributions of systems running on linux and making it do everything.
In translation... (Score:5, Informative)
"Kernel threads" will now be the default instead of "user threads." (Many BSDers cringe at this use of the term "kernel threads," since to them it represents the misapplication of a term apropriate only to a thread that runs entirely within the kernel. But the above is a usage common in the Linux world.)
This is a key step on the way to finishing the work for FreeBSD 5 and moving on to FreeBSD 6. It incorporates a highly sophisticated (some would say over-sophisticated) M:N threading system; this is where a new kernel-scheduled context is created only for threads that the userland scheduler thinks may block as opposed to having a kernel context for each thread like Linux does. It remains to be seen if the theoretical advantages of this approach will be turned into real-world advantages. I suspect that it will be a while before we know; although libkse has proven stable of late, there will be lots of additional experience acquired now that it is the default and no doubt this will result in further tuning.
Congrats to the FreeBSD team! This and the (not entirely unrelated) SMPng subsystem were the biggest steps on the way to getting FreeBSD 5 ready to take the FreeBSD mantle. It was a gamble going this route rather than the "safe" alternative of a 1:1 model, and there were times when a number of folks wondered if libkse would ever be finished. Well, now it is!
Re:In translation... (Score:1, Informative)
Despite all those arguments, I think an M:N model is st
Re:Sun now discourages M:N (Score:1, Insightful)
I personally don't believe that what's best for NT, Linux and now Solaris is necessarily best for FreeBSD, but the fact that the leading OS (NT), leading open-source OS (Linux) and leading UNIX OS (Solaris) all decided on 1:1 (belatedly in the case of Solaris) is certainly an endorsement of it.
IIRC, one of the main reasons Sun chose an M:N model for Solaris was to ease the porting of old UNIX software that assu
Re:Sun now discourages M:N (Score:5, Informative)
We have the option of running in 1:1 mode or in M:N mode with the same code, and we can support 30,000 or so threads in userspace (depending on tuning) and not use 30,000 ses of kernel resources.
As I mentionned in another response, The code we ended up with can run in both 1:1 and M:N modes and the library can be compiled to operate in either mode.
To be fair, we took a long time to do this and SUN changed thir minds on the topic when we had already decided where to go, but either way we have good threads..
It really is quite cute to hit 'H' in top and see Mozilla split into 3 threads..
We have quite a bit of cleaning up to do.. for example the cpu affinity is mostly a fiction at this time, (at least between threads) and the scheduler interractiosn need work..
As I have pointed out.. what we implemented was t thread framework that can be used to implement almost any threading model.. For example we will be able to emulate linux threads (well, we do in linux mode) but linux will not be able to emulate our threading unless they add SAs to their kernel..
We can do:
* process based (clone) threading (e.g. linuxthreads)
* process internal threads (the old single process threads)
* 1:1 system scope threads
* 1:1 process scope threads
* M:N theads with async syscalls. (SAs) We'll see which survives in 5 years :-)
Hopefully this makes a good platform for people to do thread research.. That was a big design goal.. provide general solutions that people can use their imagination to use in ways we hadn't thought of.. That's where libthr came from.. it was a surprise to us.. people whipped it up in a few weeks using the infrastrucure we'd made. (they didn't know how close we were to releasing working code so their stopgap and kse were released almost together :-)
Re:In translation... (Score:1)
LinuxThreads was 1:1 but is now deprecated.
Re:In translation... (Score:1)
Re:KSE is Kernel Schedulable Entities (Score:2)
I think some folks would disagree that libthr wasn't successful -- libkse seemed for all intents and purposes stalled until libthr came along and gave it a kick in the pants. In addition, libthr helped show how the KSE mechanism had a clean enough separation of policy and implementation to support alternative models. If at some point it's decided that the M:N model doesn't work out -- even for just a limited number of applications -- an alternative could quickly be made available. Although KSE's still a
Re:KSE is Kernel Schedulable Entities (Score:2, Informative)
KSE is not just M:N but also 1:1
The code to generate new "kernel threads" on the fly if an existing thread blocks is only a small part of what was done (though it was tricky I admit).
Re: KSE and 1:1 vs M:N,
It can be used in either way.
firstly the library can be compiled to create a separate kernel thread for each user thread,
and secondly, the thread creation process can be done in a way that guarantees a kernel thread bound to the new thread. even if the library was compile "M:N