[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: lib/46661: libpthread shouldn't provide __res_state()
> | 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
> | 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
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.
Main Index |
Thread Index |