Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 Mar 1999 03:30:39 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        dick@tar.com (Richard Seaman, Jr.)
Cc:        jplevyak@inktomi.com, tlambert@primenet.com, hackers@FreeBSD.ORG
Subject:   Re: lockf and kernel threads
Message-ID:  <199903020330.UAA22888@usr01.primenet.com>
In-Reply-To: <19990301151046.G1046@tar.com> from "Richard Seaman, Jr." at Mar 1, 99 03:10:46 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > > For user space threads and the Linux crap, the signal handling
> > > should be possible, if you follow the disallow-all-but-one-thread
> > > rule.

[ ... ]

> The shared signal handling code added to the kernel in Dec/Jan (is this
> the "Linux crap" Terry refers to?) implement 1) and 2) above.  Complete
> compliance with 3) requires more changes.  

No.  The kernel threading implementation for Linux kernel threads
that is Linux ABI compliant is what I was referring to.

The actual implementation is suboptimal.  I'd go so far as to compare
it to SVR3 shared libraries, which mapped into the same location in
all processes, and couldn't be revised without eating a new chunk of
the available address space.  It's that degree of "suboptimal" I see
there.

I see many serious issues arising since Jeremy Allison and I did the
(admitted) hacks to bring FreeBSD libpthreads into compliance with
the Draft 4 specification.

I can only say in our defense that:

1)	We brought it all into line with a documented interface,
	instead of leaving it in limbo between standards, and it
	was thus usable, perhaps moreso than the "almost standard"
	stuff that's in there now.

2)	We limited ourselves to user space, so while we were, in
	fact peeing in the pool to a degree, at least it wasn't
	the kernel.

Which isn't much, but it's the only semi-valid defense there is.


It's actually (IMO) time to step back from all of this bit-hacking
and ask "What framework would encompass all of the use models we
are trying to provide for?".

IMO, the Linux threading, in particular, and the POSIX aio and thread
interfaces, in general, represents a bunch of ill-thought-out hacks
on hacks by the respective Linux and POSIX responsible persons.  The
Linux hacks were by people who didn't know better, and the POSIX
hacks were political by people who did know better, but didn't have
the courage of their convictions.  It is time for some considered
design.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903020330.UAA22888>