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

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

The following reply was made to PR lib/46661; it has been noted by GNATS.

From: River Tarnell <river%RT.UK.EU.ORG@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: lib-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost
Subject: Re: lib/46661: libpthread shouldn't provide __res_state()
Date: Thu, 5 Jul 2012 16:37:07 +0100

 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 threa=
 d-safe
 >  | interface, using it from a single thread would appear to work fine.
  =20
 >  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).
  =20
 I've looked through the code but I don't see an obvious problem (which=20
 is not to say there isn't one, I just can't see it).  As I understand=20
 it, _res is not really used except in res_init() where it's copied to=20
 _nres, the new global structure for the non-thread-safe resolver=20
 functions (which still appear to work when -lpthread is linked, as long=20
 as the user doesn't touch _res -- at least, they don't abort).
 
 =46rom an API point of view I don't see why _res shouldn't work in=20
 programs linked against -lpthread; of course in multi-threaded programs=20
 there is a re-entrancy problem, but the programs in question do not=20
 create any threads other than the main thread (i.e., they pull in=20
 -lpthread because they are linked against other shared libraries that=20
 do, but they are single-threaded).  Is there an issue with NetBSD's=20
 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 f=
 or
 >  almost a decade now, and there is no excuse for dicking with _res direct=
 ly
 >  anymore!
 
 I don't disagree, but these functions are used in current, existing code=20
 and break popular software (such as Postfix) in certain configurations=20
 on NetBSD.  For that reason alone it would be nice if they worked as=20
 they do on other platforms.
 
        - river.