From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 18:53:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 5116816A4CE; Fri, 20 Feb 2004 18:53:08 -0800 (PST) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.10/8.12.9) with ESMTP id i1L2r7HS035861; Fri, 20 Feb 2004 21:53:07 -0500 (EST) (envelope-from green@green.homeunix.org) Received: from localhost (green@localhost)i1L2r6rR035857; Fri, 20 Feb 2004 21:53:07 -0500 (EST) Message-Id: <200402210253.i1L2r6rR035857@green.homeunix.org> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Daniel Eischen In-Reply-To: Message from Daniel Eischen From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Feb 2004 21:53:06 -0500 Sender: green@green.homeunix.org 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:53:08 -0000 Daniel Eischen wrote: > 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. Yeah, it might help a little in programs that use the resolver very heavily; I don't think I'll get to that unless I get bored enough to use the profiler, though. Worth putting on a TODO list. > > 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? It's in src/tools/regression/gaithrstress. > > 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? I'm using SCHED_4BSD (on 2 * Athlon MP); I've never tried SCHED_ULE at home. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\