Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Feb 2004 21:53:06 -0500
From:      "Brian F. Feldman" <green@FreeBSD.org>
To:        Daniel Eischen <eischen@vigrid.com>
Cc:        current@FreeBSD.org
Subject:   Re: Testers wanted: reentrant resolver 
Message-ID:  <200402210253.i1L2r6rR035857@green.homeunix.org>
In-Reply-To: Message from Daniel Eischen <eischen@vigrid.com>  <Pine.GSO.4.10.10402202123520.13965-100000@pcnet5.pcnet.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen <eischen@vigrid.com> wrote:
> On Fri, 20 Feb 2004, Brian F. Feldman wrote:
> 
> > Daniel Eischen <eischen@vigrid.com> 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 :)
> > <URL:http://green.homeunix.org/~green/reentrant_resolver.patch>;
> 
> 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.                       \,,,,,,,,,,,,,,,,,,,,,,\




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200402210253.i1L2r6rR035857>