Hi Daniel, I’m trying to confirm that there’s a bug in curl_easy_pause(). What I typically see is the following:
1. a bunch of data arrives and gets written to a buffer via the WRITEFUNCTION; 2. the buffer eventually fills up, and in the same thread, it pauses itself by returning CURL_WRITEFUNC_PAUSE; 3. another thread drains the buffer and the buffer eventually empties (or goes below the low-water mark), causing: 4. that thread to enqueue the session on a work-queue with the scheduler; 5. a periodic timer (every 250ms) runs in the original CURL thread, sees the queued paused session in the work-queue, dequeues it, clears the “paused” flag, and calls curl_easy_pause(c, CURLPAUSE_CONT); 6. immediately I see a SINGLE call to WRITEFUNCTION callback; and… that’s all she wrote. Things appear to lock-up. Even though a lot more data should have arrived, I only see a single WRITEFUNCTION callback. I’m not seeing the session being put back into a paused state. A couple of questions… 1. can we add more debugging/tracing around the unpausing function so that sufficient state is dumped that we can tell if it’s operating correctly or not? For instance, looking at data->state.tempcount and data->state.tempwrite[] instead in curl_easy_pause(). 2. can we make curl_easy_pause() callable from another thread so that we can eliminate the periodic timer in #5 above? 3. similarly, can we make curl_multi_remove_handle() callable from another thread so we can abort a transfer without the periodic timer in #5 above? I have some code that seems to indicate there’s a bug in the pausing code, but I can’t share it with the public. If I find time, I’ll try to pare it down to what’s necessary to reproduce the bug. Thanks, -Philip ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
