From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 18:27: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 999B416A4CE; Fri, 20 Feb 2004 18:27:48 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5413743D1F; Fri, 20 Feb 2004 18:27: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 i1L2RlSQ015055; Fri, 20 Feb 2004 21:27:47 -0500 (EST) Date: Fri, 20 Feb 2004 21:27:47 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: "Brian F. Feldman" In-Reply-To: <200402210202.i1L22D7K035367@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 02:27:48 -0000 On Fri, 20 Feb 2004, Brian F. Feldman wrote: > Daniel Eischen wrote: > > On Fri, 20 Feb 2004, Brian F. Feldman wrote: > > > 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. > > > > :-) > > Hah, if you would have said "put it in struct res_per_thread {}, since > h_errno is defined by the resolver(3) API anyway" it would have saved a lot > of time. Patch updated :) > This seems fine. One comment though. You might save a bit by removing the defines for: +#define s ___res_send_private()->s +#define connected ___res_send_private()->connected +#define vc ___res_send_private()->vc +#define af ___res_send_private()->af +#define Qhook ___res_send_private()->Qhook +#define Rhook ___res_send_private()->Rhook in res_send.c. You could just grab the "struct res_per_thread" at the beginning of the function, and then access the structure. It would save multiple calls to pthread_once(), pthread_getspecific(), etc. > Could you take a look at my test program (that I put in src/tools/) to see > if I made any pthreading errors? Where in src/tools? > I'd also like someone else more familiar with -lthr's kernel side to take a > look at why that's crashing... Just curious, what scheduler? -- Dan Eischen