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.
Debian GNU/kFreeBSD: FBTL
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
id:"alpine.LNX.2.00.1307102021050.4232@contest.felk.cvut.cz".
<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
id:"alpine.LNX.2.00.1308021035160.5570@contest.felk.cvut.cz"
id:"alpine.LNX.2.00.1405082034530.8707@contest.felk.cvut.cz"
id:"87wqdv1314.fsf@kepler.schwinge.homeip.net"
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.