Re: lib/46661: libpthread shouldn't provide __res_state()

[River Tarnell <river%RT.UK.EU.ORG@localhost>]

Christos Zoulas:
>  | I've looked through the code and I don't see any reason why _res can't be
>  | used from a program that links with -lpthread.  While it's not a 
> thread-safe
>  | interface, using it from a single thread would appear to work fine.
  
>  There is plenty good reason for not doing that; using the non-threaded
>  versions of the resolver variable will not just "work fine". Just read
>  the code (in res_send.c).
  
I've looked through the code but I don't see an obvious problem (which 
is not to say there isn't one, I just can't see it).  As I understand 
it, _res is not really used except in res_init() where it's copied to 
_nres, the new global structure for the non-thread-safe resolver 
functions (which still appear to work when -lpthread is linked, as long 
as the user doesn't touch _res -- at least, they don't abort).

From an API point of view I don't see why _res shouldn't work in 
programs linked against -lpthread; of course in multi-threaded programs 
there is a re-entrancy problem, but the programs in question do not 
create any threads other than the main thread (i.e., they pull in 
-lpthread because they are linked against other shared libraries that 
do, but they are single-threaded).  Is there an issue with NetBSD's 
implementation that prevents this from working?

>  Instead start using the thread-safe versions of the functions (it is
>  as simple as changing res_send() to res_nsend() for example and managing
>  your own _res_state with res_ninit()/res_nclose()). They've been there for
>  almost a decade now, and there is no excuse for dicking with _res directly
>  anymore!

I don't disagree, but these functions are used in current, existing code 
and break popular software (such as Postfix) in certain configurations 
on NetBSD.  For that reason alone it would be nice if they worked as 
they do on other platforms.

        - river.