You are not logged in.

#1 2004-05-15 18:50:05

jak
Member
From: Charlotte, NC, USA
Registered: 2004-04-08
Posts: 84

glibc nptl

Anybody testing a recent glibc snapshot with nptl? I hear nptl is much better. SuSE say they use it in 9.1.


The sturgeon general says don't smoke fish

Offline

#2 2004-05-15 20:26:34

Abaddon
Member
From: Poland
Registered: 2004-05-03
Posts: 249

Re: glibc nptl

AFAIK nptl is good on servers, not on desktops.


Gnome - The weakest link!
Linux, *not* GNU/Linux!

Offline

#3 2004-05-15 21:52:44

kakabaratruskia
Member
From: Santiago, Chile
Registered: 2003-08-24
Posts: 596

Re: glibc nptl

What is nptl?


And where were all the sportsmen who always pulled you though?
They're all resting down in Cornwall
writing up their memoirs for a paper-back edition
of the Boy Scout Manual.

Offline

#4 2004-05-15 22:08:15

jak
Member
From: Charlotte, NC, USA
Registered: 2004-04-08
Posts: 84

Re: glibc nptl

kakabaratruskia wrote:

What is nptl?

Native POSIX Thread Library.


The sturgeon general says don't smoke fish

Offline

#5 2004-05-16 02:45:56

skoal
Member
From: Frequent Flyer Underworld
Registered: 2004-03-23
Posts: 612
Website

Re: glibc nptl

jak wrote:

Anybody testing a recent glibc snapshot with nptl? I hear nptl is much better. SuSE say they use it in 9.1.

My future system will be a 2.6.x kernel with glibc NPTL.

Pros:
1. standard thread compliance, ensuring standards at all costs.
2. upto 500x faster in thread-spawning.

Cons:
* 1. Not 100% backwards compatible with traditional glibc linuxthreads.  Which means, all traditional apps. linked against linuxthreads `libpthread' can fail.  Which means, unless a distro. supports binaries linked against NPTL, you are stuck with linuxthreads linked binaries.

In a few weeks, I'll have a 2.6.x kernel with NPTL built.  I'll post back with results.

Here's a document you can read on the subject:
http://people.redhat.com/drepper/nptl-design.pdf

* It will be nice to work with POSIX compliance on Linux finally.  I remember writing a real-time app controlling a motor, and I had to use 2 different thread libraries.  `libpthread' needed a major overhaul and I can tell you timing is an issue in real time systems.  The old (current) one doesn't cut mustard in those particular instances.

Offline

#6 2004-05-16 02:54:48

kakabaratruskia
Member
From: Santiago, Chile
Registered: 2003-08-24
Posts: 596

Re: glibc nptl

jak wrote:
kakabaratruskia wrote:

What is nptl?

Native POSIX Thread Library.

That's what I knew from google, but what is it suposed to mean.


And where were all the sportsmen who always pulled you though?
They're all resting down in Cornwall
writing up their memoirs for a paper-back edition
of the Boy Scout Manual.

Offline

#7 2004-05-16 03:16:52

skoal
Member
From: Frequent Flyer Underworld
Registered: 2004-03-23
Posts: 612
Website

Re: glibc nptl

kakabaratruskia wrote:

That's what I knew from google, but what is it suposed to mean.

POSIX compliance is a set of guidelines which different OS's can follow when implementing a library, for example.  The "pthread" library which you link against when using `linuxthreads' actually means pOSIX threads.  However, I believe the current `linuxthreads' uses an older POSIX compliance, detailed in IEEE POSIX 1003.1c standard (1995).  NPTL addressess several changes since.  I think the `N' in native stands for Linux specific, since the original POSIX implementations were outlined for general UNIX systems.  If you are not familiar with threads, they basically split a task into several ones, working in "parallel" and within the same process.  In a generic sense, threads have one (or several) people doing something you need done while you do something else.  Then, you and the other guys synchronize your efforts to acheive that task faster, in loose terms, in parallel.

NPTL, implemented by developers at RedHat in 2002 I believe, was to:

1. improve performance
2. lower complexity in operation
3. allow the kernel to make all scheduling decisions
4. improved signal handling (which I can attest to from prior use of `linuxthreads' in real time apps)
5. and several other issues

* I guess the bottom line is, the new NPTL library is aimed at securing Linux in the server/client market.  And, the kernel developers worked closely with RedHat over the past few years to do just that.

Offline

#8 2004-05-16 05:32:56

kakabaratruskia
Member
From: Santiago, Chile
Registered: 2003-08-24
Posts: 596

Re: glibc nptl

Thanks.


And where were all the sportsmen who always pulled you though?
They're all resting down in Cornwall
writing up their memoirs for a paper-back edition
of the Boy Scout Manual.

Offline

#9 2004-05-16 16:37:48

i3839
Member
Registered: 2004-02-04
Posts: 1,185

Re: glibc nptl

NPTL works only with 2.6 kernels, or with heavily patched, not too stable (Red Hat) 2.4 kernels. So it won't happen till the distro uses only 2.6 kernels.

Offline

#10 2004-05-16 16:54:37

jak
Member
From: Charlotte, NC, USA
Registered: 2004-04-08
Posts: 84

Re: glibc nptl

i3839 wrote:

NPTL works only with 2.6 kernels, or with heavily patched, not too stable (Red Hat) 2.4 kernels. So it won't happen till the distro uses only 2.6 kernels.

Hope that's soon. Or I might be tempted to install SuSE 9.1.


The sturgeon general says don't smoke fish

Offline

#11 2004-05-16 20:29:04

Thikasabrik
Member
Registered: 2004-02-23
Posts: 92

Re: glibc nptl

You can try this out with Archlinux now - check out http://schoolbak.dyndns.org/nptl/
I am using it at the moment - I've had no problems, but haven't noticed a big difference on my old, slow, desktop machine anyway.

Offline

#12 2004-05-17 10:33:35

torindan
Member
From: Romania
Registered: 2004-01-13
Posts: 32

Re: glibc nptl

So when Archlinux will have it?

I saw several posts about mono and it's needs in POSIX threads, I also saw a lot of interest in java and as I know it WILL speed up java.

So may be after releasing Arch 0.7 we will move to NTPL ?

I know that ALL applications compiled with pthreads need to be recompiled with new glibc. May be a new repository must be added to test ntpl based packages and slowly migrate (and maybe Arch 1.0 will be fully ntpl)

Offline

#13 2004-05-17 15:43:30

Thikasabrik
Member
Registered: 2004-02-23
Posts: 92

Re: glibc nptl

torindan wrote:

I know that ALL applications compiled with pthreads need to be recompiled with new glibc. May be a new repository must be added to test ntpl based packages and slowly migrate (and maybe Arch 1.0 will be fully ntpl)

This is, luckily, not the case. The changes required are in glibc, and any applications that are statically linked with glibc. This means the only thing required for archlinux to work is to get the nptl versions of glibc, pacman, and cvsup. These are available from the nptl repo listed above.

Offline

#14 2004-05-18 13:00:26

jak
Member
From: Charlotte, NC, USA
Registered: 2004-04-08
Posts: 84

Re: glibc nptl

Thikasabrik wrote:

The changes required are in glibc, and any applications that are statically linked with glibc

Static linking is done at compile time, and the library code is copied into the executable. Why would statically linked applications be impaired by a new glibc?


The sturgeon general says don't smoke fish

Offline

#15 2004-05-18 16:23:04

Thikasabrik
Member
Registered: 2004-02-23
Posts: 92

Re: glibc nptl

jak wrote:
Thikasabrik wrote:

The changes required are in glibc, and any applications that are statically linked with glibc

Static linking is done at compile time, and the library code is copied into the executable. Why would statically linked applications be impaired by a new glibc?

You're right of course. The problem apparrent in using pacman and cvsup builds that are statically linked to linuxthreads glibc on a nptl system is that they are unable to resolve hostnames (as it says on the page I linked to). I am not sure exactly why this is, but I assume it is due to interaction with apps that are using nptl threads / the newer glibc generally. I am just going by that page, I did not want to find this out the hard way.

Offline

#16 2004-05-18 17:09:16

i3839
Member
Registered: 2004-02-04
Posts: 1,185

Re: glibc nptl

I would link programs that should be static (like pacman) to dietlibc or uclibc which make real static binaries possible.

Offline

#17 2004-05-19 00:40:00

skoal
Member
From: Frequent Flyer Underworld
Registered: 2004-03-23
Posts: 612
Website

Re: glibc nptl

Thikasabrik wrote:

You can try this out with Archlinux now - check out http://schoolbak.dyndns.org/nptl/
I am using it at the moment - I've had no problems, but haven't noticed a big difference on my old, slow, desktop machine anyway.

If my prior posts were misleading, there should be a 99% guarantee that the NPTL switch will work for all your existing apps.  On rarity, some existing apps will fail due to superficial differences, and prior posts mentioned as much.  The NPTL is backwards compatible with `linuxthreads'. 

A few buddies on LFS "distro" have been testing NPTL for some time and noted very few problems. A few fubars now and then should be expected when "overhauling" and migrating to a new system lib.  It's good to see that AL is on top of this migration and developers are already making that transition for us.  Thanks go out to the AL developers for the time spent doing so.  I came to AL primarily for their quick transition to the 2.6 kernel.

Offline

#18 2004-06-19 19:44:17

oldtimer
Member
Registered: 2004-06-18
Posts: 17

Re: glibc nptl

I am trying to get Mondo Backup working and find that ./configure fails due to missing "linuxthreads glibc add-on". Is the solution to this upgrading to the glibc ntpl version or do I need to get the linuxthreads add-on built for glibc? My guess would be that glibc ntpl version would do it, but what else will I break if I change glibc to the bleeding edge ntpl version? I am running the latest 2.6.7 kernel.

Offline

Board footer

Powered by FluxBB