> On Apr 2, 2018, at 3:31 AM, Daniel Stenberg <[email protected]> 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
