From 49a086299e047b18280457b654790ef4a2e5abfa Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Wed, 18 Feb 2015 00:58:35 +0100 Subject: Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn" This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1. --- open_issues/nptl.mdwn | 116 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 116 insertions(+) create mode 100644 open_issues/nptl.mdwn (limited to 'open_issues/nptl.mdwn') diff --git a/open_issues/nptl.mdwn b/open_issues/nptl.mdwn new file mode 100644 index 00000000..be0270df --- /dev/null +++ b/open_issues/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 + + Other question: how difficult is a NPTL port? Futexes and some + kernel interfaces for scheduling stuff etc. -- what else? + actually NPTL doesn't _require_ futexes + it just requires low-level locks + Mmm, it seems to be so only in principle + I can see futex names here and there in the generic code + looks like Drepper isn't disciplined enough in that area either + (well, why would he...) + I'm not sure we really want to port NPTL + OK. + Drepper will keep finding things to add + while the interface between glibc and libpthread isn't increasing + _so_ much + ... and even less so the interfavce that actual applications + are using. + We'd need to evaluate which benefits NPTL would bring. + + +# IRC, freenode, #hurd, 2013-08-05 + + Hi, looks like kfreebsd are now using an NPTL-based pthread + library: FBTL, http://lists.debian.org/debian-bsd/2013/07/msg00060.html + Anything of interest for porting to Hurd? See also + http://lists.debian.org/debian-hurd/2013/08/msg00000.html + Petr could've been more verbose in his announcements + and there's + http://www.gnu.org/software/hurd/open_issues/nptl.html in our wiki + well, it seems to work fine for kFreeBSD: + http://lists.debian.org/debian-bsd/2013/07/msg00134.html + and http://lists.debian.org/debian-bsd/2013/07/msg00138.html + + +# IRC, freenode, #hurd, 2013-12-26 + + hm? has NPTL already supported for Hurd? + probably won't ever be + so no plan for it? + what for ? + no one interested in it, or no necessary adding it? + why would you want nptl ? + ntpl was created to overcome the defficiencies of linuxthreads + we have our own libpthread + (with its own defficiencies) + supporting nptl would probably force us to implement something a + la clone + well, just inertia, now that Linux/kFreebsd has it + are you sure kfreebsd has it ? + * teythoon thought we have clone + http://www.gnu.org/software/hurd/open_issues/nptl.html + seems someone mentioned it + it's a "nptl-like implementation" + yes, I don't think it should be the same with Linux one, but + something like it + but what for ? + as mentioned in the link you just gave, " We'd need to + evaluate which benefits NPTL would bring." + well, it's the note of 2010, I don't know if it's relative now + relevant* + ah thanks + but that still doesn't answer anything + why are *you* talking about nptl ? + just saw pthread, then recall nptl, dunno + just asking + :) + but you mentioned that Hurd has its own thread implementation, + is it similar or better than Linux NPTL? + or there's no benchmark yet? + it's inferior in performance + almost everything in the hurd is inferior performance-wise because + of the lack of optimizations + currently we care more about correctness + 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... + what ? + nptl was always 1:1 + but in nptl-design draft, I thought it's m:n + anyway, it's draft + and seems being a draft for long time + never read anything like that + I think it's my misread + I have to go, see you guys tomorrow + The consensus among the kernel developers was that an M-on-N + implementation + would not fit into the Linux kernel concept. The necessary + infrastructure which would + have to be added comes with a cost which is too high. + + +--- + +# Resources + + * + + * + + * -- cgit v1.2.3