> From: MrC <[email protected]> > 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 [email protected] _______________________________________________ DCC mailing list [email protected] http://www.rhyolite.com/mailman/listinfo/dcc
