Hello Daniel,

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

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

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?

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 mutli stack" is

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

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.

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

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

l 82: required return values of these functions?

l 116-117: loss of information:
   - 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
   - Is there state we can't copy inside SSL or something?

Regards,
James Cone

At 11:49 28/03/2002 +0100, Daniel Stenberg wrote:
>Hey
>
>I've jotted down my thoughts on data sharing between curl easy handles,
>including mutex support. See details in the attachment. Read the rest here
>first.
>
>This are mostly things we've talked about already, but I've tried to sum it
>all up and present one single take on the entire sharing issue, including
>mutex protection for multi-threaded uses.
>
>I like this approach as it solves many issues at once:
>
> * works for multi-threaded libcurl easy handles
> * works for single-threaded cases too
> * shared data may survive easy handles' life times
> * works for the multi interface without the need for mutexes
> * allows existing applications to easily extend to this
> * keeps the actual mutex implementation outside of libcurl
> * solves the issue on who owns shared resources
> * easy to decide exactly what to share between which handles
>
>As always, ideas aren't worth anything unless they get support and
>improvments. Please let the rest of us know what you think about this
>approach!
>
>[I'll be away for a few days now, to give you some time to really fill up the
>list with your views on this.]
>
>--
> Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/
Received on 2002-04-02