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
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel