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:

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

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:

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.

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

Jean-Yves Migeon

Home | Main Index | Thread Index | Old Index