From owner-freebsd-current Sat Oct 31 13:27:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA18979 for freebsd-current-outgoing; Sat, 31 Oct 1998 13:27:04 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns.tar.com (ns.tar.com [204.95.187.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA18973 for ; Sat, 31 Oct 1998 13:27:03 -0800 (PST) (envelope-from lists@tar.com) Received: from ppro.tar.com (ppro.tar.com [204.95.187.9]) by ns.tar.com (8.9.1/8.8.7) with SMTP id PAA23692; Sat, 31 Oct 1998 15:26:50 -0600 (CST) Message-Id: <199810312126.PAA23692@ns.tar.com> From: "Richard Seaman, Jr." To: "John Birrell" Cc: "current@freebsd.org" Date: Sat, 31 Oct 98 15:26:50 -0600 Reply-To: "Richard Seaman, Jr." X-Mailer: PMMail 1.92 For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Kernel threading (was Re: Thread Scheduler bug) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 1 Nov 1998 07:43:04 +1100 (EST), John Birrell wrote: >Richard Seaman, Jr. wrote: >Kernel threads should use libpthread and libc, not libc_r. Agreed, sort of. I don't use libc_r. If you're going to implement deferred cancellation points, I think you still need to wrap some syscalls, so you still need to generate a separate libc somewhere. The "kernel" syscalls drop into libpthread, in a manner analagous to what happens in libc_r, but the wrappers are different, and the syscalls that are wrapped are different. >You can't mix >kernel thread syscalls with user-thread syscalls because the styles are >incompatible (blocking vs non-blocking). Agreed. A pure kernel thread implementation seems much simpler because you just get rid of all the syscall wrapping that's needed to implement user thread blocking i/o. Or, am I missing something? >You can't mix kernel thread >scheduling with user-thread scheduling. Agreed. In kernel threads the kernel scheduler does all the work. You can get rid of all the 19 pages of user thread scheduling code. >It doesn't sound like you have >made any attempt to update the user-space knowledge of the running thread. >As a result you will mix all errno codes and all user-space locking. This >is a fundamental issue that needs to be designed, not hacked. Well, the user-space knowledge of the running thread comes from pthread_self, which in the case I've implemented this comes from the code John Dyson provided to the list a while back. errno codes are returned on the thread stack, if I understand his code. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message