From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 17:24:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEC0916A4CE; Fri, 20 Feb 2004 17:24:48 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8951C43D1D; Fri, 20 Feb 2004 17:24:48 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i1L1OlSQ028424; Fri, 20 Feb 2004 20:24:47 -0500 (EST) Date: Fri, 20 Feb 2004 20:24:47 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: "Brian F. Feldman" In-Reply-To: <200402210120.i1L1KIWH014659@green.homeunix.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@FreeBSD.org Subject: Re: Testers wanted: reentrant resolver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2004 01:24:48 -0000 On Fri, 20 Feb 2004, Brian F. Feldman wrote: > Daniel Eischen wrote: > > > Other APIs have the option of failing. __h_errno() does not have the option > > > of failing, so what do I do if pthread_key_create() fails? Also, if > > > malloc() fails each time pthread_getspecific() returns NULL for the thread? > > > > The API isn't thread-safe by design, so if malloc() fails, > > just use the global errno. A better design would be to > > add the thread-safe interfaces I mention above, and have > > the non-thread-safe interfaces first do the pthread_once(), > > pthread_[gs]etspecific() thing and then call the thread-safe > > interfaces. Since the malloc() will be the first thing > > in the entry point, you can fail right away: > > Ok, just had a "good idea". Since h_errno belongs to the resolver, too, why > don't I just implement __h_errno() inside res_init.c and make the storage > come from the same place the per-thread struct _res {} storage comes from? > That should make you happy, and it makes me happy because it doesn't add an > "extra" failure point. That's exactly what I meant when I said: > > Ugh, can you put h_errno inside the per-thread res stuff. :-) -- Dan Eischen