[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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[...]
> | 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.
So because a program *may* use _res wrongly, *all* programs that use
_res (and libpthread) are broken, even those that use it correctly?
> | 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.
Postfix is broken in the sense that it doesn't work (e.g. pkg/44656).
The problem is that it's not clear whose fault it is. Postfix is the
one calling _res, but it's entirely single-threaded, so there's nothing
wrong with that. It links against the PostgreSQL client library, libpq.
libpq does not use _res (it uses the MP-safe resolv interface), but it
is MP-safe itself, and pulls in libpthread. As a result, Postfix
> 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.
The pthread API requires that pthread_mutex_init() be called, doesn't
it? So, a program not doing so is clearly wrong.
> If programs want to play with _res from a threaded context, they are
> broken and should be fixed.
But the program is single-threaded; it just happens to link against
libpthread. Why shouldn't that work?
Main Index |
Thread Index |