summaryrefslogtreecommitdiff
path: root/open_issues/nptl.mdwn
blob: be0270dff063c8ab1d929211daabb734475cc0e2 (plain)
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
[[!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.


# 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
    <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


# 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/>