On Fri, Jun 9, 2017 at 3:29 AM, Daniel Stenberg <daniel_at_haxx.se> 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
Received on 2017-06-09