Date: Sun, 15 Sep 2002 09:15:49 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Valentin Nechayev <netch@iv.nn.kiev.ua> Cc: Jev <jev@ecad.org>, hackers@FreeBSD.ORG Subject: Re: gethostbyname_r() fbsd equiv? Message-ID: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
Valentin Nechayev wrote: > 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). I think you missed earlier, where I pointed out that AIX and HP/UX now use thread local storage versions of the functions, so that their external interface is unchanged. For FreeBSD to do this, people would need to permit two changes; the first would be to erase some of the distinction between the C++ startup code (i.e. c++rt0.c) and the C version. Specifically, the .init section can be replaces, but is not itself treated as a linker set by the compiler. The C++ code that does the constructor initialization for stacically initialized constructors and pure virtual base classes *is* a linker set. What this basically means is that rather than overloading the .init (which is not allowed -- you may only override it), the ability to set up thread local storage code requires that you implement in the constructor linker set space. This, in turn, means that C programs that want to do this automatically, without needing a magic function or a "static int once = 1;" thing must be linked against the C++ code that understands the constructors. The other change that is necessary is that the void argument functions require passing of the address of argc (really, they should pass the address of the kframe structure, but since argc is the first value, passing it's address is the same thing as passing the address of the kframe struct itself). See:" /usr/src/lib/csu/i386/crt0.c for more enightenment. I have code that, if this is done, permits the implementation of the code we have been talking about. In an absolutely ideal world, there would be linker-setted "thread attach" and "thread detach" methods, which would be required to be called on pthread creation and destruction, so that it was possible to do resource tracking precreation and cleanup of thread local storage areas for any call that needed this type of thing. > For now I can't understand why thread-safe resolver from BIND >= 8.2 wasn't > imported. For applications where it is nesessary (e.g. milter filter with > extended checking of sender validity), we had to compile libbind and link > it in non-natural way.;( getaddrinfo/getnameinfo can be rewritten for > thread-safe resolver mechanically, without advanced thinking. > > P.S. BIND source has version of gethostbyaddr_r and only it should be > named as canonical. The BIND code wasn't imported for two reasons: 1) The resolver in FreeBSD is not in a separate library, it is in libc, so it is hard to track modifications to the resolver without introducing a proliferation of version numbers for the C library. This isn't easily correctable, since: a) The resolver is assumed to be part of the C library for most code b) There are programs which assume the resolver is there, which are themselves statically linked. While ELF supports linking one shared library against another, which would hid the dependency of a libc on a libresolv and allow transparent migration, the antique static linking does not support library dependencies in ELF, so all of these statically linked programs compilation would have to be changed 2) The resolver library in FreeBSD has been substantially modified by the KAME IPv6 code being imported into FreeBSD. This code substantially predates the "BIND >= 8.2" support for IPv6, which you are referencing. Probably the canonically correct thing to do would be to move the resolver out of libc. Doing this brings out such amazing opposition that it's like trying to build a new freeway, and having the residents whose houses will have to be torn down insist on being able to use their houses until you cut the ribbon on the freeway itself. If you want to pursue moving the resolver out of libc, I'll add my voice in support of the idea. However, I don't expect that you will be very successful in implementing this idea incrementally, the way everyone will demand that it be implemented, so that it doesn't impact them (after all, why do they need these extra features?). -- Terry 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?3D84B235.D6E671D6>