Re: exim 4.70 on NetBSD 5.0.1 failure

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

J.R. wrote:
> Hi,
>
> I got also some hints from the exim list about that problem:
> ---
> Well it is an issue, but again I think you've missed the key point here:
> Exim doesn't use threads, thus it does not access _res in an unsafe
> manner.
>
> It's entirely fork() based so each new process will have its own copy of
> _res which is can with as it pleases.
>
> Even so, if Exim has access to _res implemented incorrectly, we should
> probably look at fixing that. Does anyone know of a good reference
> program for whatever resolver library we're talking about?
> ---
>
> "thread safe" or "not thread safe". The point is: exim does not run on
> netbsd! Crude source code?

Nope; if it doesn't use threads, accessing _res directly is safe, as 
each new forked process has its own copy of it.

> Is there a better resolver library i can use for exim on netbsd?

Whatever resolver library you use, accessing globals not protected by 
locks in a multi threaded environment is bad practice. Using a different 
library won't change that.

Now that we know that Exim does not use pthreads, you have two solutions:
1 - convert the offending code using the old deprecated resolver(3) API 
with their "recent" counterparts, which are known to be thread safe; see:

http://netbsd.gw.com/cgi-bin/man-cgi?resolver++NetBSD-current
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/apis/resnsend.htm

2 - find why the Exim you compiled is linked against libpthread. Some 
-lpthread flag is lurking somewhere.

FWIW, just to make things clearer:

paris$ cat resolver_test.c
#include <netinet/in.h>
#include <resolv.h>
#include <stdio.h>

int main (void) {
        _res.options = RES_INIT;
        printf("Looks like it works...\n");

        return 0;

}

paris$ cc resolver_test.c
paris$ ./a.out 

Looks like it works...
paris$ cc -lpthread resolver_test.c
paris$ ./a.out 

_res is not supported for multi-threaded programs.
Abort
paris$

The ldd(1) output of your binary might be interesting.

--
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost