Re: [Fwd: Re: dccifd: restart after signal 6]

[Vernon Schryver <vjs%calcite.rhyolite.com@localhost>]

> To: tech-net%netbsd.org@localhost
> From:  christos%astron.com@localhost (Christos Zoulas)

> How many years will it take people to switch from res_foo to res_nfoo
> which is re-entrant? Really, these functions have been there for
> more than a decade. There is no excuse for a multi-threaded program
> not to use them if they are available and instead use their own
> API and do their own locking. What is next? Don't use the _r functions
> and do your own locking? Add mutexes to protect a possibly non-thread-safe
> malloc? Unless of course I am missing something, and if so I apologize.
> 99% of the programs that use _res in a multi-threaded environment do
> so incorrectly, and it is a good thing to make them use the new API's.
> Someone made a mistake exposing _res a *long* time ago. Let's not
> perpetuate it by having new code try to use it.

It is crazy to expect people to use undocument facilities.
"res_init", "res_send", and so forth appear in `man 3 resolver` on
"NetBSD 4.0.1 (GENERIC) " but the strings "nres" and "thread" do
not appear even once.

Then there is the issue of how the resolver state structure set by
res_nfoo is supposed to be communicated to the resolver inside
gethostbyname().  Putting values into a per-thread, caller-maintained
structure does nothing unless the library code knows to use the per-thread
structure instead of the common global structure.  Have you bothered
to check that changing values with res_nfoo has any effect?  Maybe set
the retry limits 1 retransmission and 1 second and then seeing how soon
a failure happens when you try to resolve a domain whose authoritative
server does not answer at all?  (I use timeo.rhyolite.com for such tests)

It is incompetent to convert _res into a run-time crash when correct or
less bad things to do are so easy and obvious.  You could easily make
threaded programs not link if they use _res.  Another tactic would be
to change the threaded version of the resolver library to use per-thread
_res structure, and to make the res_foo() functions in the threaded
resolver library call res_nfoo().

That you call abort() after writing to stderr in is emblematic of
the NetBSD problems.  It would be dicey to call syslog(), but simply
assuming that stderr has not been long since closed is at best far
too naive for anyone allowed to touch a libc source tree.

As for malloc(), I don't know what other people do, but I use it only
with sufficient locking.  It is incompetent to just assume that any
function that must obviously keep internal state is thread-safe without
explicit words in documentation.  (Never mind that I avoid malloc()
in general.)  
Besides, the crazy NetBSD philosophy would be to malloc() for
threaded applications into {printf(); abort();} and expect people
to know by mental telepathy to use an undocument function that in
fact does not work.

It is stupid egotism to change well documented names simply because
you can.  For decades starting long before NetBSD, existed people
including myself have been doing all kinds of stuff under the covers
in system libraries including libc to preserve APIs.  You only change
names as with localtime()/localtime_r() when the old API cannot be
maintained or when you want to offer an improved API. 
If for some reason you can't offer a new name, you at least document
the problem.  If you don't do that, you at least delete the old
documentation!

Of course on abstract grounds, nres_foo() is better than res_foo() just
as localtime_r() is better than localtime().  But only people who
shouldn't be allowed near a source tree would willfully and knowingly
break res_foo() without either documenting res_nfoo() or implementing
res_foo() as something like res_nfoo(pthread_getspecific())


Finally DO NOT WRITE ME about this stuff.  I care only about the
code.  I'm not interested in joining a djb style,
we-re-so-wonderful-because-we-tell-each-other-so cult.
The nature of NetBSD in this decade is clear regardless of this
_res silliness.


Vernon Schryver    vjs%rhyolite.com@localhost