[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: lib/46661: libpthread shouldn't provide __res_state()
The following reply was made to PR lib/46661; it has been noted by GNATS.
From: River Tarnell <river%RT.UK.EU.ORG@localhost>
Cc: lib-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
Subject: Re: lib/46661: libpthread shouldn't provide __res_state()
Date: Thu, 5 Jul 2012 16:37:07 +0100
> | I've looked through the code and I don't see any reason why _res can't=
> | used from a program that links with -lpthread. While it's not a threa=
> | 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=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=
> almost a decade now, and there is no excuse for dicking with _res direct=
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.
Main Index |
Thread Index |