From owner-freebsd-current Fri Dec 26 22:16:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA06775 for current-outgoing; Fri, 26 Dec 1997 22:16:04 -0800 (PST) (envelope-from owner-freebsd-current) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA06749; Fri, 26 Dec 1997 22:15:44 -0800 (PST) (envelope-from jb@freebsd1.cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.8.7/8.8.7) id RAA10165; Sat, 27 Dec 1997 17:19:02 +1100 (EST) (envelope-from jb) From: John Birrell Message-Id: <199712270619.RAA10165@cimlogic.com.au> Subject: Re: kernel threads api? In-Reply-To: <199712270559.VAA06074@hub.freebsd.org> from Jeffrey Hsu at "Dec 26, 97 09:59:40 pm" To: hsu@FreeBSD.ORG (Jeffrey Hsu) Date: Sat, 27 Dec 1997 17:19:00 +1100 (EST) Cc: freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jeffrey Hsu wrote: > Life could be simpler if we just > made libc re-entrant and not distinguish libc from libc_r or libpthread. With the work that John Dyson has done (is doing 8-) on kernel threads, libc_r can die and be replaced by libpthread + libc. This is made possible because any thread can block on a syscall and the kernel will schedule another thread. Without kernel threads, blocking syscalls are problematic to libc_r, as you know 8-). Of course there is still a lot of work required to make libc re-entrant. Regards, -- John Birrell - jb@cimlogic.com.au; jb@netbsd.org; jb@freebsd.org CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137