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 EischenReceived on Fri Feb 20 2004 - 17:27:48 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:44 UTC