> On Apr 2, 2018, at 3:31 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Sun, 1 Apr 2018, Philip Prindeville wrote:
>
>> and thinking about aborting a transfer using curl_multi_remove_handle () in a scenario like the hiperfifo.c example.
>>
>> I also added a call to check_multi_info() after the removal, as that seems to be necessary (is it?).
>
> No, it isn't.
>
> curl_multi_info_read() returns information about easy handles that are still in the multi stack. To tell the application when a specific transfer has completed.
>
> When you remove the easy handle from the stack, it won't be transfered anymore and it will therefor not complete either. It will not cause a message to be
> generated at all.
>
>> How do I properly handle the task as no longer being active?
>
> You remove the easy handle from the multi handle, that effectively stopped that transfer and prevents it from going any further. That easy handle is still identifying a transfer that you can set new options to, reset or free.
>
> If you want to restart the tranfer that easy handle represents, you add it to the multi stack again.
>

Okay, thanks. In the context of the example, then, what additional logic would be necessary?

I guess I’d have to locate the matching sockinfo_t and then call remsock() to get libevent to forget about it?

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-04-02