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
> such interrupts within CURLOPT_WRITEFUNCTION, CURLOPT_READFUNCTION and
> CURLOPT_PROGRESSFUNCTION, e.g:
>
> if(pending_interrupt()){
> return CURL_READFUNC_ABORT;
> }
>
> 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: https://github.com/jeroenooms/curl/blob/interrupt/src/utils.c#L127-L999
>
> 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].

[1]: https://curl.haxx.se/libcurl/c/curl_multi_perform.html
[2]: https://github.com/jeroenooms/curl/blob/interrupt/src/utils.c#L146-L147
[3]: https://curl.haxx.se/libcurl/c/libcurl-multi.html#BLOCKING

-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-02-06