Conference turris::digital_unix

8798.0. "gethostbyaddr & thread safe DU v3.2d?" by CSC32::K_MARTIN () Wed Feb 12 1997 01:41

Hello,
    
    We have been helping MCI implemnt PMDF on Digital Unix, mainly with
    tuning advice, since Innosoft has not benchmarked their app on DU.
    
    Now they are asking MCI to ask us about gethostbyaddr and thread safe.
    Was hoping one you internals type weenies may shed some light on the
    following:
    
    
>From: 	[email protected][SMTP:[email protected]]
>Sent: 	Monday, February 10, 1997 11:42 AM
>To: 	Proctor, Jerry
>Cc: 	Brooks, David; Kratky, Glenn; Gray, Paul D.; [email protected];
>[email protected]
>Subject: 	Re: IP ns lookup setup on GK3/GK4
>
>Thanks for the information.
>
>It's not necessarily the DNS server that is the problem, but instead the
>DNS client routines (specifically, in this case, gethostbyaddr_r()) that
>we use. 
>
>It's possible that they made them thread-safe by simply taking out a mutex
>before starting the routine and then releasing it when done. This would
>have the effect of making it such that only a single thread at a time
>could call that routine (or set of routines).
>
>To that end, I've put some new files in the FTP area (ANONYMOUS /
>MCI-TCP). There is a new tcp_smtp_server that has a fix I'll describe
>below and a new libpmdf.so (and compressed libpmdf.so-z) that is the
>latest 5.0 version but without the debugging lines that I had previously.
>
>The new tcp_smtp_server disables the gethostbyaddr_r() call (IP -> name
>lookup) when "noidenttcp" (the default) is specified. Since the only thing
>that this routine is used for is to control what gets put into the
>Received: header, it has no bearing on the deliverability of messages. 
>
>In PMDF 5.1, this same behavior can be obtained, as Kevin had mentioned in
>an earlier message, by the "identnonenumeric" keyword.
>
>It would probably be useful to understand from DEC's perspective about
>using the gethostbyname_r() and gethostbyaddr_r(), as well as the various
>res_*(), routines in a multithreaded environment. There may well be some
>issues about using them in multiple threads at the same time. For their
>information and comment, we did have to implement a special call before we
>called gethostbyaddr() to wipe 4K of the stack clean. Here is the comment
>in the code that talks about this: 
>
>	/*
>	 * OSF/1 V3.0 (and possibly later) have a serious bug in
>	 * gethostbyname_r() and gethostbyaddr_r().  Those routines
>	 * call getsvc_r() which keeps a context across calls to
>	 * itself in a scvinfo struct.  Unfortunately, that struct
>	 * is allocated on the stack!  We can avoid a problem by
>	 * ensuring the struct is wiped out between calls, which
>	 * forces getsvc_r() to refresh it on each call.
>	 */
>
>It is possible that our workaround may somehow cause incorrect behavior in
>these routines (such as failing to clean up allocated data that starts to
>slow it down after many successive calls).
>
>Anyway, please do try the new images and see how they go. I feel pretty
>good about how well they'll work on your system.
    
    
    
    Thanks,
    
    
    Keith.

gethostbyaddr is thread-safe starting in v4.0.

Even the man page says you should be using gethostbyaddr_r