pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: exim 4.70 on NetBSD 5.0.1 failure



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


Home | Main Index | Thread Index | Old Index