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
Received on 2018-05-11