diff options
Diffstat (limited to 'service_solahart_jakarta_selatan__082122541663/nptl.mdwn')
-rw-r--r-- | service_solahart_jakarta_selatan__082122541663/nptl.mdwn | 116 |
1 files changed, 116 insertions, 0 deletions
diff --git a/service_solahart_jakarta_selatan__082122541663/nptl.mdwn b/service_solahart_jakarta_selatan__082122541663/nptl.mdwn new file mode 100644 index 00000000..be0270df --- /dev/null +++ b/service_solahart_jakarta_selatan__082122541663/nptl.mdwn @@ -0,0 +1,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/> |