From 270012850bad65514eb0e48a901189a1d223d566 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 31 Jul 2010 23:56:00 +0200 Subject: open_issues/nptl: New. --- open_issues/nptl.mdwn | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 open_issues/nptl.mdwn (limited to 'open_issues') diff --git a/open_issues/nptl.mdwn b/open_issues/nptl.mdwn new file mode 100644 index 00000000..daec8b11 --- /dev/null +++ b/open_issues/nptl.mdwn @@ -0,0 +1,27 @@ +[[!meta copyright="Copyright © 2010 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]] + +IRC, #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. -- cgit v1.2.3