4 ms·

> Then it needs to sort them if there is more than one address. And in order to do that it needs to read /etc/gai.conf I don’t see why glibc would have to do t

> Then it needs to sort them if there is more than one address. And in order to do that it needs to read /etc/gai.conf I don’t see why glibc would have to do that inside a call to getaddrinfo. can’t it do that once at library initialization? If it has to react to changes to that file while a process is running, couldn’t it have a separate thread for polling that file for changes, or use inotify for a separate thread to be called when it changes? Swapping in the new config atomically might be problematic, but I would think that is solvable. Even ignoring the issue mentioned it seems wasteful to open, parse, and close that file repeatedly.

loeg 1y ago
I think the libc people might argue this level of functionality is just outside the scope of libc. (Arguably, it is a mistake for DNS to be part of libc, given how complicated it is.)
- ComputerGuru 1y ago
  To be sure, complexity isn’t the determinator for whether something is or isn’t in scope for libc though.
  - loeg 1y ago
    Historically libcs have been leery of imposing threading on otherwise singlethreaded applications; and for similar reasons, try to minimize startup costs.
- Someone 1y ago
  https://sourceware.org/glibc/ https://sourceware.org/glibc/ says “The GNU C Library is designed to be a backwards compatible, portable, and high performance ISO C library. It aims to follow all relevant standards including ISO C11, POSIX.1-2008, and IEEE 754-2008.” ⇒ I don’t think they make that argument.
  - loeg 1y ago
    The standards make no requirement that an implementation be good, performant, or even useful.
NewJazz 1y ago
You want libc to start a thread whenever it is loaded?
- Someone 1y ago
  If it’s the only alternative to being broken: yes. It could read and parse the file the first time a thread gets created, too. A cheaper alternative is to check the modification time of the config file, and only reparse it in pthread_cancel when that changes. That doesn’t 10% fix the problem in theory, but would do it in practice.
cesarb 1y ago
> I don’t see why glibc would have to do that inside a call to getaddrinfo. can’t it do that once at library initialization? If it were a library dedicated to DNS, sure, but glibc is used by nearly every process in the system, including many which will never call getaddrinfo.

loeg 1y ago

I think the libc people might argue this level of functionality is just outside the scope of libc. (Arguably, it is a mistake for DNS to be part of libc, given how complicated it is.)

ComputerGuru 1y ago
To be sure, complexity isn’t the determinator for whether something is or isn’t in scope for libc though.
- loeg 1y ago
  Historically libcs have been leery of imposing threading on otherwise singlethreaded applications; and for similar reasons, try to minimize startup costs.
Someone 1y ago
https://sourceware.org/glibc/ https://sourceware.org/glibc/ says “The GNU C Library is designed to be a backwards compatible, portable, and high performance ISO C library. It aims to follow all relevant standards including ISO C11, POSIX.1-2008, and IEEE 754-2008.” ⇒ I don’t think they make that argument.
- loeg 1y ago
  The standards make no requirement that an implementation be good, performant, or even useful.

NewJazz 1y ago

You want libc to start a thread whenever it is loaded?

Someone 1y ago
If it’s the only alternative to being broken: yes. It could read and parse the file the first time a thread gets created, too. A cheaper alternative is to check the modification time of the config file, and only reparse it in pthread_cancel when that changes. That doesn’t 10% fix the problem in theory, but would do it in practice.

cesarb 1y ago

> I don’t see why glibc would have to do that inside a call to getaddrinfo. can’t it do that once at library initialization? If it were a library dedicated to DNS, sure, but glibc is used by nearly every process in the system, including many which will never call getaddrinfo.