1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
|
[[!meta copyright="Copyright © 2010, 2013, 2014 Free Software Foundation,
Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]
[[!tag open_issue_libpthread open_issue_glibc]]
[[!toc]]
# IRC, freenode, #hurd, 2010-07-31
<tschwinge> Other question: how difficult is a NPTL port? Futexes and some
kernel interfaces for scheduling stuff etc. -- what else?
<youpi> actually NPTL doesn't _require_ futexes
<youpi> it just requires low-level locks
<youpi> Mmm, it seems to be so only in principle
<youpi> I can see futex names here and there in the generic code
<youpi> looks like Drepper isn't disciplined enough in that area either
<tschwinge> (well, why would he...)
<youpi> I'm not sure we really want to port NPTL
<tschwinge> OK.
<youpi> Drepper will keep finding things to add
<youpi> while the interface between glibc and libpthread isn't increasing
_so_ much
<tschwinge> ... and even less so the interfavce that actual applications
are using.
<tschwinge> We'd need to evaluate which benefits NPTL would bring.
# Debian GNU/kFreeBSD: FBTL
## IRC, freenode, #hurd, 2013-08-05
<gnu_srs> Hi, looks like kfreebsd are now using an NPTL-based pthread
library: FBTL, http://lists.debian.org/debian-bsd/2013/07/msg00060.html
[[!message-id "alpine.LNX.2.00.1307102021050.4232@contest.felk.cvut.cz"]].
<gnu_srs> Anything of interest for porting to Hurd? See also
http://lists.debian.org/debian-hurd/2013/08/msg00000.html
<azeem> Petr could've been more verbose in his announcements
<pinotree> and there's
http://www.gnu.org/software/hurd/open_issues/nptl.html in our wiki
<azeem> well, it seems to work fine for kFreeBSD:
http://lists.debian.org/debian-bsd/2013/07/msg00134.html
<azeem> and http://lists.debian.org/debian-bsd/2013/07/msg00138.html
## [[!message-id "alpine.LNX.2.00.1308021035160.5570@contest.felk.cvut.cz"]]
## [[!message-id "alpine.LNX.2.00.1405082034530.8707@contest.felk.cvut.cz"]]
## [[!message-id "87wqdv1314.fsf@kepler.schwinge.homeip.net"]]
# IRC, freenode, #hurd, 2013-12-26
<nalaginrut> hm? has NPTL already supported for Hurd?
<braunr> probably won't ever be
<nalaginrut> so no plan for it?
<braunr> what for ?
<nalaginrut> no one interested in it, or no necessary adding it?
<braunr> why would you want nptl ?
<braunr> ntpl was created to overcome the defficiencies of linuxthreads
<braunr> we have our own libpthread
<braunr> (with its own defficiencies)
<braunr> supporting nptl would probably force us to implement something a
la clone
<nalaginrut> well, just inertia, now that Linux/kFreebsd has it
<braunr> are you sure kfreebsd has it ?
* teythoon thought we have clone
<nalaginrut> http://www.gnu.org/software/hurd/open_issues/nptl.html
<nalaginrut> seems someone mentioned it
<braunr> it's a "nptl-like implementation"
<nalaginrut> yes, I don't think it should be the same with Linux one, but
something like it
<braunr> but what for ?
<braunr> as mentioned in the link you just gave, "<tschwinge> We'd need to
evaluate which benefits NPTL would bring."
<nalaginrut> well, it's the note of 2010, I don't know if it's relative now
<braunr> relevant*
<nalaginrut> ah thanks
<braunr> but that still doesn't answer anything
<braunr> why are *you* talking about nptl ?
<nalaginrut> just saw pthread, then recall nptl, dunno
<nalaginrut> just asking
<braunr> :)
<nalaginrut> but you mentioned that Hurd has its own thread implementation,
is it similar or better than Linux NPTL?
<nalaginrut> or there's no benchmark yet?
<braunr> it's inferior in performance
<braunr> almost everything in the hurd is inferior performance-wise because
of the lack of optimizations
<braunr> currently we care more about correctness
<nalaginrut> speak the NPTL, I ever argued with a friend since I saw
drepper mentioned NPTL should be m:n, then I thought it is...But finally
I was failed, he didn't implement it yet...
<braunr> what ?
<braunr> nptl was always 1:1
<nalaginrut> but in nptl-design draft, I thought it's m:n
<nalaginrut> anyway, it's draft
<nalaginrut> and seems being a draft for long time
<braunr> never read anything like that
<nalaginrut> I think it's my misread
<nalaginrut> I have to go, see you guys tomorrow
<braunr> The consensus among the kernel developers was that an M-on-N
implementation
<braunr> would not fit into the Linux kernel concept. The necessary
infrastructure which would
<braunr> have to be added comes with a cost which is too high.
---
# Resources
* <http://www.akkadia.org/drepper/nptl-design.pdf>
* <http://nptltracetool.sourceforge.net/>
* <http://posixtest.sourceforge.net/>
|
