On Tue, 21 Aug 2007, Shmulik Regev wrote:

> Your mileage may vary of course - especially if a limited number of SSL_CTX
> objects are allocated. This heavily depends on the usage pattern.

Thanks for the timing info. I fully understand how hundreds of milliseconds
can make a difference.

>> Does this assumption about properties remaining the same really make sense?
>
> I think that under most usage patterns the location of the trusted
> certificates file/directory is the same as well as the client certificate.
> Do you have a different view of it? Once we agree on the set of possibly
> varying "keys" to the cache (currently only the method is), I can easily
> change the caching strategy.

I fully agree that most programs, in fact most likely all programs, will use
the same values for these options during the program's entire lifetime. But
that's not really a reason why we should make the assumption that it will
always be so and thus not even notice when the situation changes.

I want our code to be written as robust as possible with a "least-surprise"
guide. Having subsequent transfers with modified options not actually "get"
the new options (as caching the objects without caring for the options would
cause) would make libcurl's behaviour very strange from the view of an
application author.

Hence I advocate that we only re-use SSL_CTX objects that have the same
options set. In 99.3% of all real-life applications, that will still mean that
all objects can be re-used by all handles.

>>> The SSL_CTX objects (one per SSL_METHOD) are managed by the share instance
>>> and are freed only when the share is.
>>
>> If we're adding this, I would rather like to see the multi handle introduce
>> automatic caching/sharing of CTX objects between the easy handles added to
>> it. In a similar manner to how it does for other caches.
>>
> I'm not sure I fully understand your intent, but are you suggesting we move
> it out of the share and into the multi?

Not quite. I'm quite happy with it being a part of the share interface as then
two independent easy handles can be made to re-use these objects and thus get
speedier operations.

What I meant is that when two easy handles are added to a multi handle, they
could be told to automatically share the SSL_CTX objects. This is how the DNS
cache and more already works. They are part of the share interface to allow
them to be shared between easy handles, but the multi handle does some of this
magic for us to make multi transfers better and faster without a lot of extra
setup necessary. The upside with this is also that all existing multi-
interface using applications (built with OpenSSL) will benefit from this code
immediately.

>> Some nits in the code:
>
> Thanks for letting me know. I fixed it (though I'll send the patch once we
> agree on its contents). It is worth noting that MSVC doesn't warn about
> uninitialized variables when running with warning level 3, nor does it warn
> about unused parameters (it does on unused variables). Warning level 4 is
> better but it warns about a couple of other issues (like initial_tv not
> being initialized in select.c and other stuff). If you want I can work on
> solving these warnings.

I'm not really aware of the differences between level 3 and 4 and if it is
worth the effort of removing warnings to that extent. The nits I mentioned
were found with gcc and good old human eyes review. :-)

BTW, I didn't see it and I don't have the patch handy right now to check, but
what's the maximum amount of objects added to the cache? I mean, when are they
pruned from it?

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html