From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 17:08:15 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 947C016A4CE; Fri, 20 Feb 2004 17:08:15 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52F9F43D1F; Fri, 20 Feb 2004 17:08:15 -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 i1L18ESQ024276; Fri, 20 Feb 2004 20:08:14 -0500 (EST) Date: Fri, 20 Feb 2004 20:08:14 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: "Brian F. Feldman" In-Reply-To: <200402210048.i1L0mVGW014390@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:08:15 -0000 On Fri, 20 Feb 2004, Brian F. Feldman wrote: > Daniel Eischen wrote: > > On Fri, 20 Feb 2004, Brian F. Feldman wrote: > > > > > Daniel Eischen wrote: > > > > Ugh, can you put h_errno inside the per-thread res stuff. > > > > We shouldn't need to have to add special hooks in the > > > > threads libraries for this. > > > > > > Please explain what you're saying further. On correctly-threaded operating > > > systems, h_errno is just like errno -- and I made it act EXACTLY as errno > > > acts, and is per-thread storage for everything but the first thread. It's > > > absolutely necessary if we want to return the correct errors; even if > > > everything else in the world is totally reentrant, if h_errno isn't, the > > > wrong errors can be returned! What "special hooks" do you mean? There's no > > > way to not change probably hundreds of lines of code without actually doing > > > the work to make h_errno thread-safe. It's the only proper thing to do. > > > > The implementation of __h_errno() need not depend on something > > special stuffed in struct pthread. Use thread-local storage > > (pthread_getspecific()) like you did for the res_send_private > > stuff. Especially since these interfaces should be deprecated > > in favor of what looks to be BIND 8.2.2 interfaces (according > > to the Solaris man pages). > > 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: /* MT-safe */ int res_nsend(res_state statp, const u_char *msg, int msglen, u_char *answer, int anslen) { ... } /* Not MT-safe */ int res_send(const u_char *msg, int msglen, u_char *answer, int anslen) { res_state statp; if (pthread_once(...)) { ... } statp = pthread_getspecific(res_key); if (statp == NULL) { /* Allocate statp. */ pthread_setspecific(res_key, statp); } return (res_nsend(statp, msg, msglen, answer, anslen)); } -- Dan Eischen