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

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

On Jul 5,  5:08pm, river%RT.UK.EU.ORG@localhost (River Tarnell) wrote:
-- Subject: Re: lib/46661: libpthread shouldn't provide __res_state()

| So because a program *may* use _res wrongly, *all* programs that use 
| _res (and libpthread) are broken, even those that use it correctly?

Define correctly. If a program is linked against -lpthread, nothing
prevents other things that it is linked with to use threads and/or
the resolver functions.

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

Correct.

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

Because it cannot possibly know what other things it calls that use pthreads
are doing. Anyway, the I just fixed postfix, and it will probably get fixed
upstream too.

christos