Testers wanted: reentrant resolver

[Daniel Eischen]

On Fri, 20 Feb 2004, Brian F. Feldman wrote:

> Daniel Eischen <eischen at 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.

> 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