From owner-freebsd-hackers Mon Mar 1 19:32:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id E3BD514C87 for ; Mon, 1 Mar 1999 19:31:02 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id UAA25163; Mon, 1 Mar 1999 20:30:45 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp03.primenet.com, id smtpd025140; Mon Mar 1 20:30:41 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id UAA22888; Mon, 1 Mar 1999 20:30:39 -0700 (MST) From: Terry Lambert Message-Id: <199903020330.UAA22888@usr01.primenet.com> Subject: Re: lockf and kernel threads To: dick@tar.com (Richard Seaman, Jr.) Date: Tue, 2 Mar 1999 03:30:39 +0000 (GMT) Cc: jplevyak@inktomi.com, tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <19990301151046.G1046@tar.com> from "Richard Seaman, Jr." at Mar 1, 99 03:10:46 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > 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