________________________________ From: curl-library <curl-library-boun...@cool.haxx.se> on behalf of bch via curl-library <curl-library@cool.haxx.se> Sent: 09 October 2019 08:01 To: libcurl development Cc: bch; Daniel Stenberg Subject: [DKIM] Re: Stoppable curl_easy_perform ?
On Mon, Oct 7, 2019 at 23:50 Daniel Stenberg via curl-library <curl-library@cool.haxx.se<mailto:curl-library@cool.haxx.se>> wrote: On Mon, 7 Oct 2019, Dan Fandrich via curl-library wrote: >> curl_easy_stop(easy); > > Now it's time to bike shed :-) This name implies to me something like > "pause" in that you might expect to be able to start it again later. I'm > guessing once this is called, the transfer is toast, forever. > curl_easy_abort() would make that a bit more clear, since this isn't a clean > operation. It also aligns with the error code CURLE_ABORTED_BY_CALLBACK > which would be my first choice as to what code would be returned by > curl_easy_perform() if this were called (barring creating a new error code). Thanks. I'll refer to it as curl_easy_abort() from now on for the reasons you outline. I've been thinking of a new and separate return code for clarity: CURLE_ABORTED and if trying to abort a transfer that hasn't been setup to allow it: CURLE_ABORT_DENIED. > Off the top of my head CURLE_ABORT_DENIED -might- make sense, but even that > maybe not... is there not a case for (at least my) idiomatic: > > if(CURLE_OK!=curl_easy_abort(...)) { > ... > } > > this is just a pass/fail of the "abort" verb, no? I guess it's not that new > codes cost much, but does it buy anything? But even then curl_easy_abort(...) must return something that is not CURLE_OK. Since other codes do not seem appropriate, it needs a new one IMHO.
------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
