On Tue, 2 Apr 2002, J. Cone wrote:

> No-one else has replied, that I can see, so I guess it's mine.

Someone has to jump first! ;-) Thanks a lot for reading through this and for
giving feedback and thoughts.

My updated version of the original suggestion is now stored and browsable
here: http://curl.haxx.se/dev/sharing.txt

Reminder: this is just a suggestion. Nothing is set. Nothing is decided.
Every detail is still subject for debate and discussion.

> l 4: curl_chare_create: deliberate typo to see if anyone reads it?

Eeeh, yes let's call it that!

> l 37-38: share only when told => same functionality:
> - I would assume sharing should preserve the previous definition of
> correctness
> - ie in the absence of errors it should cause no change in apparent behaviour
> - do you have an example of useful sharing where this is not true?

No, no sharing at all is what is done today and by defaulting to that for
everything, we don't change the expected behavior in future versions either.

There are shares, however, that have obvious benefits for libcurl users to
take advantage from almost no matter what kind of intended usage. DNS caching
is one example of such.

> l 40..: needs mutexes:
> - if you intend to have two handles, that share, used potentially
> concurrently in different threads?
> - I don't know what a "single multi stack" is

A 'multi stack' is what you get and deal with when you use the (rather new
and still not very tested) libcurl multi interface. The man pages for that
are included in the upcoming release archive, in the CVS and the
multi-overview man page can be browsed from here:
http://curl.haxx.se/libcurl/c/libcurl-multi.html

(The other man pages are still not browsable on the web, but I'm working on
getting them to show up there.)

> l 45, 66: Don't change horses in mid-stream:
> - can these ruled be enforced in the implementation?
> eg by reference counting
> - a ~detach everything and make a list so they can be attached later~
> option is probably prohibitive

Yes, both these requirements can be ensured in run-time. Trying to break any
of them will only cause an appropriate return code to get returned.

> l 75: Why don't ssl sessions and connections need mutexes? If they did,
> the list of shareable things could do duty for the list of mutexable things.

Yes, that list is only for showing the basic idea, I didn't intend it to be
complete. Both SSL sessions and connections will get their own entry in that
table, as you correctly point out.

> How do I cancel a mutex? eg pass in NULL lock & unlock pointers

Right, I should add some text about that. If you set NULL for both functions,
we disable the mutex use.

> What's CURL_MUTEX_NONE? - lock/unlock has no effect?

Nothing really. I just do that out of habit (adding a _NONE first in the
list), to prevent the first "actual" enum to have a value of zero. I'll add
a comment about it.

> l 82: required return values of these functions?

I haven't really thought about this yet. I figure that the mutex callback
functions should return zero if everything is fine, or non-zero if they fail
somehow.

I can't think of any reason for anything else being returned.

> l 116-117: loss of information:

I've been thinking about this and I'm not sure this way is the best way to
deal with "unsharing" info. It could be a point to specificly have an UNSHARE
option to remove a specific share from an easy handle. Supporting that,
*could* allow us to make one easy handle use several "independent" shares,
all sharing different data:

Imagine three threads named A, B and C. A shares cookies with B but not with
C, B shares SSL sessions with C but not with A.

I'm not sure I can come up with any *realistic* use case though, why
supporting this may only add complexity without any real-world gain.

> - this is scary
> - I understand that ceasing to share might mean (eg) opening new
> connections (probably when they're needed) and setting them into the same
> state the shared connection was in

Telling an easy handle to no longer use a share is a rather drastic move, and
yes, it should not be done without caution. Still, by documenting clearly
what will happen when doing so, we at least leave the choice to the
programmer with all information that (s)he might need to make the decision.

No longer using a share in which we have previously stored data, will force
the handle to use default values or add new values to its own private caches.

> - Is there state we can't copy inside SSL or something?

We cannot copy SSL session IDs for example. That is, I haven't found any
external APIs for that, we might be able to hack one up but I can't see any
reason why we should.

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/