KExtendedSocket async lookup

Thiago Macieira thiagom at
Thu Aug 1 22:19:38 BST 2002

Hash: SHA1

Waldo Bastian wrote:
>> That could be a problem, yes. But I could find no other way of doing an
>> asynchronous lookup without using the undocumented, GNU-specific
>> getaddrinfo_a() function.
>Using getaddrinfo_a where available might be a solution if we can get some
>guarantee that it will not disappear in the next version of glibc.

As I mentioned before, it's GNU-specific, so it's a solution only to systems 
based on the GNU libc. Aside from that, it's not documented in the texinfo 
documentation (nor is getaddrinfo() for that matter). What I have found is a 
proposal paper by Ulrich Drepper from Red Hat:

If we choose that way to go, I'd need some insight on how to check that the 
result is done. It's possible to use a signal, but that is not recommended 
for a library. The other choice is to check whether the job is done at each 
Qt loop.

Another possibility that the paper suggests is the use of threads.

>Oh, maybe I misunderstood then... is the sync code _always_ doing IPv6
> lookups even if we don't have working IPv6 support?

No. The not-right-thing is being done at this time. When kdecore is compiled 
with IPv6 stack detection or without IPv6 lookup, we change the AF_UNSPEC 
lookup into an AF_INET one. But that's a compilation-time option that is 
disabled by default -- it's only a workaround.

>That would explain why disabling IPv6 kernel support didn't help for

This guy seems to have a problem with his DNS server, which is slow for AAAA 
lookups (Mozilla is IPv6-enabled too).

Another thing: the IPv6 stack detection routine might very create the stack 
we're trying to see if it exists. On Linux, that happens if net-pf-10 is 
aliased to ipv6.o (/etc/modules.conf)

- -- 
  Thiago Macieira - UFOT Registry number: 1001
 thiagom at
   ICQ UIN: 1967141  PGP/GPG: 0x6EF45358
     Registered Linux user #65028
Version: GnuPG v1.0.7 (GNU/Linux)


More information about the kde-core-devel mailing list