dccifd: restart after signal 6

Vernon Schryver vjs@calcite.rhyolite.com
Sat Jun 6 00:17:27 UTC 2009


> From: MrC <lists-dcc@cappella.us>

> Here's the abort() in the libpthread version of res_state:

>              static const char res[] = "_res is not supported for 
> multi-threaded"
>                  " programs.\n";
>              (void)write(STDERR_FILENO, res, sizeof(res) - 1);
>              abort();
>              return NULL;
>      }

That is utterly lame, overprotective mommy-ism.  Besides, it stupidly
assumes that stderr has not been closed, as competent programmer does
in a daemon.

A competent programmer knows to suspect that a library is not thread
safe unless it explicitly says it is.  More than that, you assume that
a library that keeps internal state like _res.options and res_init()
is not thread safe unless it both claims to be thread safe and you can't
find any evidence about problems.

And to omit any hint of the nonsense in the resolver man page!
There is this passing mention in resolve.h:
 * Source and Binary compatibility; _res will not work properly
 * with multi-threaded programs.


> And dccifd is linked against libpthread:

Because dccifd and dccm use threads


> Let me know if there is something I can do to help.

Any suggestions on the least nasty kludge to link dccifd and dccm
to the libc resolver intead of the broken-by-design libpthread
resolver?  I'd have to force not only the res_state hooks, but the
whole resolver edifice including anything called inside gethostby*().

Should I change the Makefiles to treat NetBSD like Windows and not build
dccifd and dccm under the toy-applications-for-toy-operating-systems rule?

Maybe I can arrange to not tweak the resolver timeouts for the threaded
DCC programs to limit the total DCC delays and so keep SpamAssassin and
MTAs from being unhappy.


Have I mentioned I'm becoming ever less enamored of recent versions of
NetBSD?  The Linux experts only gratuitously, incompatibly changed the
names of the resolver hooks.


thanks any way,
Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.