Yes, there are certain conditions under which curl_multi_perform can block, especially in weak network conditions. Here are a few potential reasons for this:

1. DNS Resolution: If the DNS resolution takes a long time, it can cause blocking. By default, cURL performs synchronous DNS resolution, which can block the entire process if the DNS lookup is slow. You can mitigate this by using cURL with asynchronous DNS resolution, such as c-ares or similar.

2. SSL/TLS Handshake: The SSL/TLS handshake process, which is necessary for establishing secure connections over HTTPS, can be time-consuming, especially over weak network connections. This process might block if it takes too long.

3. Network Timeouts and Retries: In weak network conditions, packet loss and high latency can lead to repeated retries and extended timeouts, which might cause curl_multi_perform to appear blocked.

4. Blocking Callbacks: If any of the callbacks (like the write, read, or progress callbacks) registered with cURL perform blocking operations themselves, they can cause curl_multi_perform to block.

5. Socket Operations: While curl_multi_perform is designed to be non-blocking, the underlying socket operations might block under certain conditions, particularly if the operating system’s network stack or the server is not responsive.

To address these issues, you can:

• Use Asynchronous DNS: Enable asynchronous DNS with c-ares. This can be done by building cURL with c-ares support and using the appropriate cURL options to enable it.

• Tune Timeouts: Set appropriate timeouts for various stages of the connection process using options like CURLOPT_TIMEOUT, CURLOPT_CONNECTTIMEOUT, and CURLOPT_DNS_SERVERS.

• Use Non-blocking Sockets: Ensure that sockets are set to non-blocking mode. cURL typically handles this, but it’s good to double-check.

• Monitor and Debug: Use verbose mode (CURLOPT_VERBOSE) to get detailed logs of what cURL is doing. This can help you pinpoint where the blocking occurs.

Here is an example of how you can set some of these options:

CURLM *multi_handle;
CURL *easy_handle;

multi_handle = curl_multi_init();
easy_handle = curl_easy_init();

curl_easy_setopt(easy_handle, CURLOPT_URL, "https://example.com");
curl_easy_setopt(easy_handle, CURLOPT_TIMEOUT, 30L);
curl_easy_setopt(easy_handle, CURLOPT_CONNECTTIMEOUT, 10L);
curl_easy_setopt(easy_handle, CURLOPT_VERBOSE, 1L);

curl_multi_add_handle(multi_handle, easy_handle);

int still_running;
do {
    CURLMcode mc = curl_multi_perform(multi_handle, &still_running);

    if (mc == CURLM_OK) {
        int numfds;
        mc = curl_multi_wait(multi_handle, NULL, 0, 1000, &numfds);

        if (mc != CURLM_OK) {
            fprintf(stderr, "curl_multi_wait() failed, code %d.n", mc);
            break;
        }

        if (!numfds) {
            fprintf(stderr, "No file descriptors ready.n");
            usleep(100000); // Sleep for a bit to avoid busy-looping
        }
    } else {
        fprintf(stderr, "curl_multi_perform() failed, code %d.n", mc);
        break;
    }
} while (still_running);

curl_multi_cleanup(multi_handle);
curl_easy_cleanup(easy_handle);

This example sets a timeout for the overall request and the connection phase, and also uses curl_multi_wait to efficiently wait for activity on the file descriptors. Adjusting these parameters can help mitigate blocking issues in weak network conditions.