On Fri, Jun 9, 2017 at 3:29 AM, Daniel Stenberg <[email protected]> wrote:
> On Thu, 8 Jun 2017, Justin Karneges wrote: > >> I'm wondering if I could implement in this behavior in our app without >> needing to modify libcurl, by using a multi instance per domain, and >> destroying a multi instance after it's been around for the maximum time. Is >> it efficient to have lots of multi instances? Right now we have just one >> master multi instance. > > > > There's really no problem with having multiple multi handles from > libcurl's perspective. > > The problem you might get is with driving the transfers. Doing multiple > multi interface transfers in a single thread would either require you to > call curl_multi_perform() on all handles as soon as one has traffic, or > you'd need to somehow remember which handle is responsible for which file > descriptors... > In our case, we have a class that manages the multi handle and its associated file descriptors, so maintaining multiple multi handles and driving the right one based on particular fd activity seemed to be as simple as instantiating the class multiple times. What I've decided to do is have one "current" multi handle and one or more "old" multi handles. New requests are always assigned to the current handle. After T time, the current handle is moved into the bucket of old handles, and a fresh handle becomes the new current handle. The old handles keep operating on any existing requests. An old handle is not destroyed by time passing, but is destroyed once the number of requests it services reaches zero. I think this should give us the right effect of eventually causing new persistent connections to be made, without destroying active requests over existing connections. Worst case outcome is we end up with a 1:1 ratio of easy to multi, if exactly one active request (e.g. a long/slow streaming request) remains with each multi handle and thus the phased out multi handles linger around. But if multi handles are cheap then maybe this is okay. Justin
------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
