Re: Stoppable curl_easy_perform ?

On Mon, 7 Oct 2019, Christopher Head via curl-library wrote:

> How would this work with multi?

First: not at all.

I appreciate that you bring this up because I have been thinking about it and
I want to offer something for that as well. Here's my thinking:

In the multi interface case we don't have the exact same need since the API is
mostly non-blocking so to stop a transfer you just remove an easy handle from
the multi handle and it stops immediately.

We do however have the curl_multi_wail/poll function that can sit waiting for
activity on multiple transfers and *that* (those) might warrant something to
allow a separate thread to abort it. (Requested in PR4418:
https://github.com/curl/curl/issues/4418)

I've thought about such a function as "curl_multi_unblock" - as the primary
use of it would be to unblock such a blocking function. Possibly we should
make it do both: stop an individual transfer *and* make the multi function
unblock. It would be fun to hear what people can think of in terms of use case
and functionality here to help us choose path forward.

*However*, what complicates the situation in the multi interface case
significantly is that we don't have any mutex function anywhere to piggyback
on, like I've proposed for the easy interface. The share interface and its
functionality is only between easy handles and there's no such thing for the
multi interface.

A multi interface stop/unblock function therefore also needs to introduce a
mutex for the multi handle. The easiest way to do this is probably to
introduce new callbacks to curl_multi_setopt() for lock/unlock...

> If the expected behaviour is (1), it seems that curl_multi_stop should be a
> thing, and then really it ought to be possible to stop a curl_multi_perform
> without damaging *any* of its easies, and perhaps then resume it (and all of
> its easies) later.

If all we do is an "unblock", then it doesn't affect the transfers at all it
just returns from the libcurl function early. If we indeed opt to stop the
function, we should rather switch to Dan's suggested terminology and call it
"abort" because we will truly abort the transfer in a way that cannot simply
be resumed.

-- 
  / 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