Date: Fri, 20 Feb 2004 20:20:18 -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: <200402210120.i1L1KIWH014659@green.homeunix.org> In-Reply-To: Message from Daniel Eischen <eischen@vigrid.com> <Pine.GSO.4.10.10402201952560.19828-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen <eischen@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.
--
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?200402210120.i1L1KIWH014659>