Date: Sun, 15 Sep 2002 19:43:55 +0300 From: Valentin Nechayev <netch@iv.nn.kiev.ua> To: Terry Lambert <tlambert2@mindspring.com> Cc: Jev <jev@ecad.org>, hackers@FreeBSD.ORG Subject: Re: gethostbyname_r() fbsd equiv? Message-ID: <20020915164354.GA275@iv.nn.kiev.ua> In-Reply-To: <3D84B235.D6E671D6@mindspring.com> References: <20020913145830.GB41842@ecad.org> <3D820700.DB53B0F9@mindspring.com> <20020913160214.GB42538@ecad.org> <3D820DD0.985F9C66@mindspring.com> <20020915111422.GA1077@iv.nn.kiev.ua> <3D84B235.D6E671D6@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sun, Sep 15, 2002 at 09:15:49, tlambert2 (Terry Lambert) wrote about "Re: gethostbyname_r() fbsd equiv?": >> SUSv3 doesn't know any gethostbyname_r. One can select either HP-UX/AIX >> or Solaris/Linux version of interface, but the more correct way is possibly >> to inplement getaddrinfo() in thread-safe way. getaddrinfo() is known >> even for Microsoft (latest versions). TL> I think you missed earlier, where I pointed out that AIX and HP/UX TL> now use thread local storage versions of the functions, so that their TL> external interface is unchanged. I didn't missed it. But I think that any interface which directly reflects multithread environment is rather preferrable than interface which relies on thread-local storage crutch. Of course, in Unix, where each little syscall requires TLS to deal with errno, this isn't already important:( Of course, old-style interface, which can be thread-safely implemented only with TLS, should exist and be safe. But only interface which directly deals with buffers should be announced as preferrable. This is useful even for code clarity. This is why I told about gethostbyname_r. gethostbyname (old) is question of real implementation, not calling convention. TL> For FreeBSD to do this, people would need to permit two changes; TL> the first would be to erase some of the distinction between the TL> C++ startup code (i.e. c++rt0.c) and the C version. This is long and hard way. Importing of thread-safe resolver, which has now interface without implicit TLS using, and netdb interface without implicit TLS using is much easier and will allow parallel usage effectively immediately. If code is already using multithreading, which means wide use of multithreading special functions, it isn't hard to use thread-safe netdb/resolver functions. TL> Specifically, the .init section can be replaces, but is not itself [...] I won't discuss this stuff because I don't know it, totally. This wasn't object of my previous replic. TL> The BIND code wasn't imported for two reasons: TL> 1) The resolver in FreeBSD is not in a separate library, it is TL> in libc, so it is hard to track modifications to the resolver TL> without introducing a proliferation of version numbers for the TL> C library. This isn't easily correctable, since: TL> a) The resolver is assumed to be part of the C library TL> for most code All this isn't a reason not to do one carefully controlled merging of resolver code from more-less new version. I ain't say nothing on automatic usage of this code, it's isn't in local tradition in any way. OTOH it's possible to make separate libresolv which contains newer code. TL> 2) The resolver library in FreeBSD has been substantially modified TL> by the KAME IPv6 code being imported into FreeBSD. This code TL> substantially predates the "BIND >= 8.2" support for IPv6, which TL> you are referencing. This is another factor which can be considered as real. (It is not factor for me because I think IPv6 is dead-born and will repeat history of X.25 and other committee-designed products. But you can think different.) TL> If you want to pursue moving the resolver out of libc, No. :) /netch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020915164354.GA275>