Re: Stoppable curl_easy_perform ?
Date: Tue, 8 Oct 2019 23:01:49 -0700
On Mon, Oct 7, 2019 at 23:50 Daniel Stenberg via curl-library <
curl-library_at_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?
-bch
> --
>
> / daniel.haxx.se | Get the best commercial curl support there is - from
> me
> | Private help, bug fixes, support, ports, new features
> | https://www.wolfssl.com/contact/
> -------------------------------------------------------------------
> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette: https://curl.haxx.se/mail/etiquette.html
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2019-10-09