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

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

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