| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 5 | |
Trolls, Does anyone know why QHostInfo explicitly loads in libresolv.so when all it does is all getaddrinfo() & getnameinfo()? I can see no where in the code where it's actually trying to do real DNS queries. It seems like a waste of time & resources to do this. Can someone enlighten me here? The reason I'm asking is that I was writing some code to subclass QAbstractFileEngine* and during the Handler::create routine, I needed to do a host lookup. This resulted in a deadlock because QAbstractFileEngineHandler::create() takes a long on the mutex the fileHandlerList, and my code calling QHostInfo::lookupName() required the same lock to load in libresolv.so. Darin Broady dbroady1@xxxxxxxxx
Darin Broady wrote: >Trolls, > >Does anyone know why QHostInfo explicitly loads in libresolv.so when all > it does is all getaddrinfo() & getnameinfo()? I can see no where in > the code where it's actually trying to do real DNS queries. It seems > like a waste of time & resources to do this. Can someone enlighten me > here? It would be loaded indirectly anyways if the resolution comes to DNS. On NSS systems (such as Linux), the libc calls like getaddrinfo and getnameinfo will read /etc/nsswitch.conf and will load the modules in order. libnss_dns.so links to libresolv.so. Anyways, the reason why we do it directly is to reinitialise the resolver routines. It's in order to fix the following scenario: 1) user loads Qt app Foo 2) user connects to the Internet using a dial-up 3) user tries to use the Foo app, that was already running, to browse the Internet The step #2 will modify /etc/resolv.conf. Without reinitialising the routines, the new config will not be loaded and the DNS lookups will most likely fail. >The reason I'm asking is that I was writing some code to subclass > QAbstractFileEngine* and during the Handler::create routine, I needed > to do a host lookup. This resulted in a deadlock because > QAbstractFileEngineHandler::create() takes a long on the mutex the > fileHandlerList, and my code calling QHostInfo::lookupName() required > the same lock to load in libresolv.so. I'd suggest you postpone the name resolution until a later point in time. In any case, network routines inside a file engine do not seem like a good idea to me. The file engines are supposed to be fast, without network wait times. You can also suggest to qt-bugs@xxxxxxxxxxxxx that we call the create() instances without a lock being held. It makes sense, but I can't promise anything now without analysing the impact of the change. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Thiago, Maybe I'm misunderstanding how the NSS libraries work. Why should the application (Qt) have to worry about if some configuration file that is used through NSS changed? In this example, it could be that the hosts entry may not be served through DNS at all -- it may just be files, or NIS, or LDAP (not saying that these are good ideas, just examples). Given this, shouldn't it be libnss_dns.so responsibility to reinitialize the resolver library when it find that the /etc/resolv.conf has changed, and not the application (Qt)? Also, what about systems that run NSCD, where the underlying protocol NSS libraries aren't even loaded into the application? As for doing the network calls inside of the file engine classes, that's the only way I've found that you can have QFileDialog display the contents of a directory shared only through FTP. I've created an FtpFileEngineHandler & FtpFileEngine to deal with this. Is there a better way to do that? Darin Broady dbroady1@xxxxxxxxx ----- Original Message ---- From: Thiago Macieira <thiago.macieira@xxxxxxxxxxxxx> To: qt-interest@xxxxxxxxxxxxx Sent: Tuesday, April 22, 2008 5:29:24 PM Subject: Re: [Qt4.3+] Why does QHostInfo load libresolv.so? Darin Broady wrote: >Trolls, > >Does anyone know why QHostInfo explicitly loads in libresolv.so when all > it does is all getaddrinfo() & getnameinfo()? I can see no where in > the code where it's actually trying to do real DNS queries. It seems > like a waste of time & resources to do this. Can someone enlighten me > here? It would be loaded indirectly anyways if the resolution comes to DNS. On NSS systems (such as Linux), the libc calls like getaddrinfo and getnameinfo will read /etc/nsswitch.conf and will load the modules in order. libnss_dns.so links to libresolv.so. Anyways, the reason why we do it directly is to reinitialise the resolver routines. It's in order to fix the following scenario: 1) user loads Qt app Foo 2) user connects to the Internet using a dial-up 3) user tries to use the Foo app, that was already running, to browse the Internet The step #2 will modify /etc/resolv.conf. Without reinitialising the routines, the new config will not be loaded and the DNS lookups will most likely fail. >The reason I'm asking is that I was writing some code to subclass > QAbstractFileEngine* and during the Handler::create routine, I needed > to do a host lookup. This resulted in a deadlock because > QAbstractFileEngineHandler::create() takes a long on the mutex the > fileHandlerList, and my code calling QHostInfo::lookupName() required > the same lock to load in libresolv.so. I'd suggest you postpone the name resolution until a later point in time. In any case, network routines inside a file engine do not seem like a good idea to me. The file engines are supposed to be fast, without network wait times. You can also suggest to qt-bugs@xxxxxxxxxxxxx that we call the create() instances without a lock being held. It makes sense, but I can't promise anything now without analysing the impact of the change. -- [ signature omitted ]
On Wednesday 23 April 2008 16:18:33 Darin Broady wrote: > Maybe I'm misunderstanding how the NSS libraries work. ÂWhy should the > application (Qt) have to worry about if some configuration file that is > used through NSS changed? ÂIn this example, it could be that the hosts > entry may not be served through DNS at all -- it may just be files, or NIS, > or LDAP (not saying that these are good ideas, just examples). ÂGiven this, > shouldn't it be libnss_dns.so responsibility to reinitialize the resolver > library when it find that the /etc/resolv.conf has changed, and not the > application (Qt)? ÂAlso, what about systems that run NSCD, where the > underlying protocol NSS libraries aren't even loaded into the application? Yes, libnss_dns should do it, but it doesn't. So we have to do it. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.