curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: Stoppable curl_easy_perform ?

From: bch via curl-library <>
Date: Tue, 8 Oct 2019 23:01:49 -0700

On Mon, Oct 7, 2019 at 23:50 Daniel Stenberg via curl-library <> 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

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?


> --
> / | Get the best commercial curl support there is - from
> me
> | Private help, bug fixes, support, ports, new features
> |
> -------------------------------------------------------------------
> Unsubscribe:
> Etiquette:

Received on 2019-10-09