Testers wanted: reentrant resolver
Daniel Eischen
eischen at vigrid.com
Fri Feb 20 17:24:48 PST 2004
On Fri, 20 Feb 2004, Brian F. Feldman wrote:
> Daniel Eischen <eischen at vigrid.com> wrote:
> > > Other APIs have the option of failing. __h_errno() does not have the option
> > > of failing, so what do I do if pthread_key_create() fails? Also, if
> > > malloc() fails each time pthread_getspecific() returns NULL for the thread?
> >
> > The API isn't thread-safe by design, so if malloc() fails,
> > just use the global errno. A better design would be to
> > add the thread-safe interfaces I mention above, and have
> > the non-thread-safe interfaces first do the pthread_once(),
> > pthread_[gs]etspecific() thing and then call the thread-safe
> > interfaces. Since the malloc() will be the first thing
> > in the entry point, you can fail right away:
>
> 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.
:-)
--
Dan Eischen
More information about the freebsd-current
mailing list