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. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green_at_FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\Received on Fri Feb 20 2004 - 16:20:20 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:44 UTC