• Thomas Haller's avatar
    connectivity: avoid busy looping with connectivity-check failed · 884a28b2
    Thomas Haller authored
    It seems, curl_multi_socket_action() can fail with
    
      connectivity check failed: 4
    
    where "4" means CURLM_INTERNAL_ERROR.
    
    When that happens, it also seems that the file descriptor may still have data
    to read, so the glib IO callback _con_curl_socketevent_cb() will be called in
    an endless loop. Thereby, keeping the CPU busy with doing nothing (useful).
    
    Workaround by disabling polling on the file descriptor when something
    goes wrong.
    
    Note that optimally we would cancel the affected connectivity-check
    right away. However, due to the design of libcurl's API, from within
    _con_curl_socketevent_cb() we don't know which connectivity-checks
    are affected by a failure on this file descriptor. So, all we can do
    is avoid polling on the (possibly) broken file descriptor. Note that
    we anyway always schedule a timeout of last resort for each check. Even
    if something goes very wrong, we will fail the check within 15 seconds.
    
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903996
    884a28b2
nm-connectivity.c 22.3 KB