Adding asynchronous name resolution to GlibC (was: Reproposed F19 Feature: Fix Network Name Resolution)

[Björn Persson]

Nick Jones wrote:
> One feature I would like to see added to future glibc, is a fully 
> asynchronous version of getaddrinfo, and also getnameinfo.
> 
> Asynchronous for non filesystem fds at least.
> 
> The glibc maintainers don't seem to be against this idea and I am 
> willing to put time into design and implementation.

May I ask why you want to do that in GlibC? Are such functions
specified by some standard, such as Posix or a new version of ISO C? Or
are you proposing them for inclusion in such a standard?

I mean, I believe some asynchronous name resolution libraries for C
exist already, but if you want to do it better, or just differently,
then sure, no problem, but why in GlibC and not as a separate library?

I know there's a tradition of vendors adding their own nonstandard
extensions to their implementations of the standard C library, sometimes
with identical names but different specifications, but I'd like that
practice to stop. This differentiation of LibC implementations is one
of the big reasons why it's difficult to write portable programs in C,
requiring complex configuration scripts to test for available features
and enable different workarounds on different operating systems. It
would have been much better if all the LibCs had remained
implementations of the C standard and maybe Posix, and not much else.
Additional features could in many cases have been separate libraries.
We have to live with the mess now, but let's not make it worse please.

If your functions get added to GlibC, then they will only be available
in GNU systems (unless other vendors decide to clone them) and programs
that use them will be tied to GNU or will need workarounds in their
configuration scripts in order to be portable. If you make them a
separate, portable library, then they can be installed on all Unix-like
systems, and maybe other operating systems too, and programs that use
them will also be portable. Wouldn't that be better?

Björn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130118/84d174d6/attachment-0001.sig>