Why does the application cleans the easy handle? If one wants to reuse
an easy handle for
a new connection, then just reuse it.
The SSL_CTX is simply reused as it is.

When using MANY easy handles, then sharing makes sense, but this
can then be done in an easier way (at least with openssl).
Create only new SSL_CTX when you have to modify some parameter with one
of the set functions. You can SSL_CTX_dup an existing one first.
when a new SSL is added to it, there is a reference count logic to
indicate how many SSLs are pointing
to it. Or, in other words, openssl already supports sharing of SSL_CTXs.

Daniel Stenberg wrote:
> On Sun, 25 Feb 2007, Shmulik Regev wrote:
>
>> I wanted to suggest another addition to libcurl - I've recently
>> patched libcurl to support caching and reusing of SSL_CTX objects.
>> Creation of these objects, and their configuration (primarily reading
>> the cacerts file) adds around 200 ms per instantiation on my machine
>> (win XP, dual core, 3 Ghz, 2 GB RAM) which is not something to ignore
>> if it is frequently done (and in my case it is). The logic is simple
>> - instead of freeing a CTX object we save it for later reuse in a
>> global list of objects. Currently I've implemented this using a
>> global object, but this was just a proof of concept and such an
>> approach doesn't really fit into the libcurl design. I think the
>> Share object is a more natural container for such a cache. Are you
>> interested in such an enhancement? If so, do you agree the Share
>> object is the proper place to add it?
>
> Yes, I think it sounds like a good addition and having it added to the
> share object seems like the logical place for it, as it would allow
> several easy handles to share the same pool of SSL_CTX objects.
>
> I guess that by default we can have this SSL_CTX caching made per easy
> handle, when used with the easy interface and per multi handle when
> the multi interface is used. Similar to how the connection cache is
> shared now. Of course we need a sensible max number of objects kept in
> the cache.
>