Conference turris::digital_unix

>     "My code makes calls to the res_init and res_query calls and modifies
>     the _res global structure.  I need to do this in a way that
>     modifications to _res only affect 1 thread rather than all threads."

	You should have also asked what they are modifying in that
	structure and why.  From what I can tell that appears to be
	an *internal* data structure (hence why it begins with _).
	If we knew why/what they are modifing there may be alternatives ....

>     Does anyone have the answer to this question.  A lot of internet
>     servers are on the line.....

	one way would be to use a mutex and sequentialize all
	(direct or indirect) calls to functions that reference _res....
	the problem is someone you don't expect to call (directly
	or indirectly) those functions will show up and break you ....

The res_ interfaces were not designed for what you want to do. They rely on
the concept of a single global structure. There is no way to make it work
independently in multiple threads.

While it's possible to make the current interface "thread-safe" by locking a
mutex (either within the libc routine or around each call), as suggested in
.1, that's not the same as maintaining separate states in each thread.

So you're asking for entirely new interfaces, and you should create a product
requirements document detailing what you need, and why. While you're at it,
describe exactly what it is that you want to change in the structure, and
why; and presumably a substantially cleaner interface could be devised.

Presumably, the result would be something like res_init_r (struct _res_state
*state); and res_mkquery_r (struct _res_state *state, ...);. That is, you
would initialize a particular (and possibly per-thread) state structure,
modify that structure as needed, and use it to perform multiple independent
queries.

	/dave

    As I would like to create some product requirements it is much easier
    for the customer to stay with HP :-(.
    
    Todd
    

> As I would like to create some product requirements it is much easier
> for the customer to stay with HP :-(.

	So you are not even going to ask the customer as both Dave and
	I have asked, as to why/what they are trying to do!?  There may
	be an alternative the customer did not think of that does *not*
	require what they think they need.  We can't respond if we don't
	know what they want.  Get with it guy!

	And what did the customer say about the suggestion in .1?

    
    I am "with it" thank you.  I have talked to the customer and will
    continue to do so.  They are NOT willing to change their code
    significantly from all of the other platforms.  I mentioned that we
    may have other ways to do this but they said that they did not have
    time to explain what they needed.  
    
    Thank you for letting me know how to do my job. I appreciate it.
    If I have any more insight I will let you know.
    
    

.3> it is much easier for the customer to stay with HP

I wonder how HP managed to make this possible....

> _What_ did they *do*?

	Todd just told us he doesn't want us telling us how to do
	his job.  He'd rather have Digital lose the sale :-(

    
    Thank you for your response.  I wouldn't rather have Digital lose
    the sale.  I just don't need your attitude.  I asked a straight forward
    question that the customer forwarded to me.  I talked to him about
    our initial response and he stated that he did not have the time to
    talk about his issues as he was under a severe time crunch.  He was
    trying to port his code quickly to give us a chance to run a benchmark.
    He told me that the benchmark will be run asap and that he would be
    happy to work with us next time.  For now they will buy another HP.
    
    Thank you Jeff for your support.

> Thank you for your response.  I wouldn't rather have Digital lose
> the sale.  I just don't need your attitude.

	We ask straight forward and logical questions and we have the
	attitude?  Go look in the mirror dude!

	It's no surprise Alpha sales are down 30% this Q if that's
	the attitude of our sales/pre-sales force.

	I also notice you now deleted your base note.  Why?

    Anybody got a recent HP box with this res stuff and man pages on it?
    Be nice to see what's up thread-wise....
    

    Todd asked me to talk with the customer to gather more technical
    information about the customer needs.  I am a System Integration
    technical type working for the week at AOL.
    The customer is using the res_ calls as a hack to get AOL customer
    data.  Their application modifies the _res struct to contain the IP
    address of an AOL server and then uses res_mkquery() to query that
    server for the AOL customer info.  They need a thread-safe version of
    these calls to allow them to query different AOL servers in different
    threads of the same process.  When prompted about using a mutex,their
    response was that they hesitate to block a thread for performance
    reasons.
    HP has provided them with a thread-safe version of these calls.
    
    Would it be possible for me to get a copy of the sources for the res_
    calls, so as to try to hack them to make the AOL hack work.
    
    Clair Garman
    NSIS

    If you let me know the question, I would check, but the answers 
    offer me only a guess, so in brief, what was the question.
    
    Pit

    Somehow the original note got deleted.  It read:
    
    "My code makes calls to the res_init and res_query calls and modifies
     the _res global structure.  I need to do this in a way that
    modifications to _res only affect 1 thread rather than all threads."
    
    Thanks
     

    The standard HP-UX 9.05 and 10.01 resolver(3N) man pages claim that the
    resolver code is the Berkeley code and have only editorial differences
    between them. resolv.h and nameser.h on 10.01 have copyright statements
    from Berkeley and Digital only and the following version IDs:
    
    /*
     *      @(#)resolv.h    8.1 (Berkeley) 6/2/93
     *      $Id: resolv.h,v 4.9.1.6 1993/11/12 01:23:43 vixie Exp $
     */
    
    /*
     *      @(#)nameser.h   8.1 (Berkeley) 6/2/93
     *      $Id: nameser.h,v 4.9.1.7 1993/12/06 00:42:58 vixie Exp $
     */
    
    
    -Tom

> Would it be possible for me to get a copy of the sources for the res_
> calls, so as to try to hack them to make the AOL hack work.

	Looks like the FreeBSD project has some non-ecumbered version(s)
	of the resolver doing an index search (I had to search on res_send,
	searching on resolver only found man pages) on gatekeeper.dec.com.
	The directories that contain sources are:

/pub/BSD/FreeBSD/FreeBSD-current/src/contrib/bind/res
/pub/BSD/net1/src/lib/libc/net
/pub/BSD/net2/lib/libc/net

    You can also get various versions of the BIND "tarballs" from the
    source site:
    
    	ftp://ftp.isc.org/isc/bind/
    
    -Tom

I'd still like to know what (if anything) HP did to make per-thread GLOBAL
_res variables. It's simply not possible without an API significantly
different from that in our man pages.

Of course, HP doesn't have "real threads" (strictly user-mode DCE threads,
until 10.30 comes out), so maybe they provided some hack to simply prevent
context switching within the hack res_init/res_mkquery segment of code?

You could also make the current APIs work by turning _res into a
thread-specific data key... but then code that wanted to change the fields of
the thread-specific _res structure would need to know the value of the key.
Writes to the global _res variable would be ignored.

The only other option, without changing APIs, would be to lock a mutex before
the res_init and only unlock after the thread was completely done with the
_res context... something they apparently don't want to do. Maybe HP did that
implicitly -- but I don't see how they could given the interfaces. (Unless
they lock before setting up _res within res_init, and unlock after the first
query to res_mkquery, assuming there would be no more from that thread
without another res_init?)

And, as for "attitude", I'm with Jeff Michaud. It's a real pain to go out of
our way to try to provide someone with help only to have them whine and
complain, delete the original topic, and slink away without giving enough
information to actually DO anything about it. It makes me kinda wonder why I
bother to read these notes conferences and answer questions at all. Luckily,
not everyone is like Todd...

	/dave