cURL / Mailing Lists / curl-library / Single Mail


Re: curl_easy_perform + interrupt

From: Ray Satiro via curl-library <>
Date: Sat, 6 Feb 2016 16:07:13 -0500

On 2/6/2016 2:07 PM, Jeroen Ooms wrote:
> The R programming language exposes a C function pending_interrupt()
> which we can use to check if the user has sent a SIGINT in the GUI.
> For the R libcurl bindings, we use curl_easy_perform() and check for
> if(pending_interrupt()){
> }
> However users have complained that this mechanism doesn't always work
> well. For example if the server stalls during the initial connecting
> phase or ssl handshake, none of the callback functions is triggered
> and SIGINT gets ignored. This causes the GUI to freeze until timeout.
> I am now exploring a different approach: I implemented a new function
> curl_perform_with_interrupt() which is a drop-in replacement of
> curl_easy_perform() however with checking for interrupts. My first
> pass is here:
> This seems to work but it looks ugly and I am not confident that this
> covers all edge cases. I was wondering if there is a more elegant
> method, or existing examples of how to implement something like
> curl_easy_perform() while reliably catching interruptions at any stage
> of the connection?

I see your remedy was to switch from blocking to non-blocking. My
understanding of multi_perform (I last read it over a year ago I think)
is that it's possible for it to always be performing, or in other words
(my words) it can essentially block if there's always pending read or
write. I had thought that was a strange choice because how would you add
more handles if it's always out performing, and in fairness here my
interpretation might be wrong and I don't remember what the responses
were when I asked about that. Hopefully someone more experienced can
weigh in here. I'd guess in such a case you'd be covered by leaving the
check for interrupts in your callbacks.

Prior to version 7.20 it appears curl_multi_perform could return even if
data was pending [1]. Your code has made it so in that case it continues
to perform without checking for interrupts [2]. That seems like the
opposite of what you want. It's a minor issue though since 7.20 is like
6 years old. Another thing in your code, there's no curl_multi_wait, why?

Also note known issues where multi currently blocks [3].


List admin:
Received on 2016-02-06