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

[christos%zoulas.com@localhost (Christos Zoulas)]

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

From: christos%zoulas.com@localhost (Christos Zoulas)
To: River Tarnell <river%RT.UK.EU.ORG@localhost>, 
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 11:52:39 -0400

 On Jul 5,  4:37pm, river%RT.UK.EU.ORG@localhost (River Tarnell) wrote:
 -- Subject: Re: lib/46661: libpthread shouldn't provide __res_state()
 
 | 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?
 
 No there is not, but there is no way to know that the program will use
 one thread to call the resolver once linking with -lpthread.
 
 | 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.
 
 Postfix itself is not broken, other things linking in it are. This
 is why we have pkgsrc, so that we can patch them, fix them and send
 the fixes back to mainline. This is similar to the issue with have
 with mutexes: requiring pthread_mutex_init() before using them;
 other OS's don't and people claim NetBSD is broken. If programs want to
 play with _res from a threaded context, they are broken and should be
 fixed.
 
 christos