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

[River Tarnell <river%RT.UK.EU.ORG@localhost>]

Christos Zoulas:
>  | 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 
doesn't work.

>  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?

        - river.