#2504 async client sockets block for DNS

obsolete: 8.3.2

The geturl documentation claims that, geturl will
return immediatly with a token if the -command option
is invoked.
If geturl can not make the initial socket connection to
a url, it blocks until the timeout expires and calls
the -command proc before geturl has returned a token.
This causes at least the following two problems:

1. The block causes any following geturl calls to hang
before processing. This destroys the asynchronious

2. It invokes the -command proc with a token that is as
yet unknown to the general processing loop.



  • Logged In: YES

    Problem (still in 8.5a0) is that [socket -async] still does
    the hostname -> IP address synchronously. Which I've known
    about for ages, but it is really hard to fix.

    The problem is that the OS interface for doing the mapping
    is itself purely synchronous and a completely monolithic
    mess. Working around that requires a helper process or
    thread, and hence the whole thing is rather complex to fix.

    • labels: 105670 --> 27. Channel Types
    • priority: 5 --> 7
    • assigned_to: hobbs --> andreas_kupries
  • Don Porter
    Don Porter

    • summary: geturl connection out of order --> async client sockets block for DNS
  • Logged In: YES

    I can name that extension on windows in 45 minutes..

    Does BSD have anyway to do an async gethostbyname?
    Does this fall into OS specific for sol/irix/linux/etc.. ?

  • Logged In: YES

    The problem is the sheer complexity of stuff hidden under
    the covers. If it was just DNS (or if there was a sensible
    way of parsing the config files across all platforms),
    that'd be so much easier.

  • Logged In: YES

    Joe English suggests using getaddrinfo() for name lookups
    instead of gethostbyname(). In terms of portability, it
    seems to be available identically on Linux, Solaris and IRIX
    for sure (no access to other Unix platforms!) and it is also
    the subject of standardization (see POSIX 1003.1g and RFC
    2553). IOW, perfect! And if there are platforms which don't
    support it, we could detect that in configure and fall back
    to the bad old gethostbyname() for [socket -async] processing.

  • Logged In: YES

    getaddrinfo() works on windows, too. But where's the spec
    for timeout behavior? Just for fun, I've been experimenting
    with an external helper app to be used for async name
    lookups. If we launch it in an async pipe, problem solved.


  • Logged In: YES

    Doesn't seem to have any defined or controllable timeout
    behaviour. You might (on POSIX systems) be able to use a
    signal, but the result of doing so is undefined.

  • Could also use a subprocess to do the resolution specifically for HTTP.

  • Worth looking at doing something about this (well, at least for the http package) after TIP #409 is done.

    • assigned_to: andreas_kupries --> coldstore
    • status: open --> open-later