On Tue, Dec 02, 2003 at 01:52:01AM +0100, Robert Millan wrote:
> On Mon, Dec 01, 2003 at 06:00:06PM -0500, Perry E.Metzger wrote:
> >
> > Porting to a Glibc-based from another is kids play.
> >
> > You aren't listening. The threads stuff is not kids play.
> > [...]
>
> The threads stuff is not as relevant nor as complicated as you pretend. I've
> been working with libpth (and so has the NetBSD 1.6 libc based port) and
> haven't found any incompatibility yet. At some point we'll study which of
> porting NPTL or porting the pthreads from NetBSD's libc is a more viable
> option.
>
> If you want to help or propose a solution, that's fine, but stop playing
> devil's advocate which is just a waste of my time.
*bzzzt*
The NetBSD/native port has been stalled for some time, because I ran into
core, required-to-build-lots-of-things applications (tcl8.4, IIRC, in
particular) that *don't work* with GNU pth. Period. Neither version 1.x or
2.x.
Speaking as someone who has co-written SA stuff (granted, for toy operating
systems that were proof-of-concept, not enterprise support), it is neither
trivial nor easy, and speaking as someone who has patched the innards of
both NetBSD's kernel and libc, and who has to figure out policy for Debian
packages to not make it easy for users to end up with unbootable systems,
the kernel and the libc are deeply intertwined, and in few places moreso
than the threading stuff.
Remember, Glibc *is* the Linux libc, these days; that means that folks put
a lot of effort into ensuring that it will support Linux, because otherwise
no Linux system can run. The motivation to port such a complex part of it
to an OS whose *fundamental assumptions* about threading are *fundamentally
different* - 1:1 vs M:N is about as different as it gets - seems a bit
iffy, to me.
While I'd dearly love to see a bit more de-coupling of NetBSD kernel and
libc (so that they don't have to be in quite such lockstep, though I'm more
worried about the process utilities that must be *exact* matches), I don't
claim that managing it would be trivial, and may not even be practical (or
at least, might not be feasible short of 3.0).
> > > In a few months I started two ports and brought them to a stage that
> > > took years for a group of people to attain.
> >
> > Ever hear of the 80/20 rule? I easily believe you can get the thing
> > very far along inside a couple of months. Trying to make it actually
> > bulletproof for production use -- especially with all the bells and
> > whistles complete -- is not the same thing.
>
> And that doesn't apply to the other port? Well, I think we should postpone the
> discussion untill the port is ready for production use, in a pair of weeks.
I'll be happy to write some applications which (legitimately) use hundreds
of threads at a time, and load-test it for you. Or, if you'd rather, I can
do some scientific software that can fire off as many thousand threads as
you'd like, all vying for the same shared mmaped memory. :)
I know NPTL on Linux handles this, and I'm reasonably confident that
native threads on NetBSD -current will handle it as well. Until your port
can handle it, I wouldn't trust it enough to call it threadsafe (and yes,
that means no version of Linux prior to NPTL is threadsafe, in my opinion
- having had to deal with it in such a context, I'm quite certain it
*isn't*).
--
Joel Baker <fenton@debian.org> ,''`.
Debian GNU NetBSD/i386 porter : :' :
`. `'
`-
Attachment:
pgpdSWxemnrJ2.pgp
Description: PGP signature