From owner-freebsd-stable Wed Jun 17 14:50:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA15087 for freebsd-stable-outgoing; Wed, 17 Jun 1998 14:50:04 -0700 (PDT) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA15000 for ; Wed, 17 Jun 1998 14:49:50 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.8.8/8.8.7) id HAA12635; Thu, 18 Jun 1998 07:55:56 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199806172155.HAA12635@cimlogic.com.au> Subject: Re: is libc_r broken in 980520-SNAP (and stable?)? In-Reply-To: from Tom at "Jun 17, 98 12:27:29 pm" To: tom@uniserve.com (Tom) Date: Thu, 18 Jun 1998 07:55:55 +1000 (EST) Cc: jb@cimlogic.com.au, edmond@shaman.lycaeum.org, stable@FreeBSD.ORG, monty@tcx.se X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tom wrote: > One thing that confuses me is that how does libc_r from 2.2.6-stable and > -current compare these days? They used to be identical, but now that > -current is getting kernel support for threads and alpha stuff, I assume > that they must be quite different now. Primarily, is libc_r from > 2.2.6-stable just as usable as libc_r from current? Highwind Software > (www.highwind.com) has a beta version of their news software that it is > statically linked to a libc_r with fixes they say they got from you. > Would this be a -stable libc_r or a -current libc_r that they are using? Highwind are only using 2.2.6 with libc_r built from the RELENG_2_2 branch. The -current libc_r differs substantially from the -stable implementation because it supports just the POSIX style of signal handling where there are one set of signal handlers declared for the threaded process, not one set per thread. This allows -current to avoid blocking signals as part of it's scheduler. This is what drains performance for some applications. The version of libc_r in the RELENG_2_2 contains fixes for all bugs that people have reported. In Highwind's case, they have code that did things like read/write with zero bytes; and write to a read only file. These caused libc_r to hang waiting on a file descriptor to become ready when it never would. Most software doesn't do this sort of thing. It seems to come from C++ code. 8-) Kernel threads in 3.0 actually have nothing to do with libc_r. They require a libpthread and a thread-aware libc. The -current libc_r implementation works on FreeBSD/Alpha. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message