From 95878586ec7611791f4001a4ee17abf943fae3c1 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/g3Ccalpj0NhN566pHbUl6i9QF0QEkrhlfPM-#b1c14" Date: Mon, 16 Feb 2015 20:08:03 +0100 Subject: rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn --- open_issues/nptl.mdwn | 116 -------------------------------------------------- 1 file changed, 116 deletions(-) delete mode 100644 open_issues/nptl.mdwn (limited to 'open_issues/nptl.mdwn') diff --git a/open_issues/nptl.mdwn b/open_issues/nptl.mdwn deleted file mode 100644 index be0270df..00000000 --- a/open_issues/nptl.mdwn +++ /dev/null @@ -1,116 +0,0 @@ -[[!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