On Mon, 6 Jan 2003, Jean-Philippe Barrette-LaPierre wrote:

> I was thinking that it might by interresting to implement a read/write lock
> system to work with the global_dns_cache, using the mutexes and the mutex
> functions.

I disagree. One of the reasons why I specificly mention DNS cache in the
sharing system is because I want that system to be used if an application
wants to share DNS cache data between multiple curl handles.

I'll even consider removing the global DNS cache once we have the share
system working with the DNS cache.

> By using this will restrict API users to give only a simple mutex system,
> they will not be able to make their own system. But when I check the source
> code, it will be difficult to create their own locking system (read/write
> or something like that), without complexifying all our API functions.

I don't understand you here. What does our current design draft not allow
and what changes are you suggesting?

> We need to decide if the sharing API we offer must be used by the users
> just to give us the possibility to get the best of it, or let the user the
> most flexibility, but adding more complexity to the API, because at this
> time it's not possible with the current API design to get the possibility
> for the user to create his oen read/write mechanism.

Why would the user want/need a read/write mechanism of locks/mutexes?

We lock a section by calling the mutex callback with a specific ID for the
lock we want. We unlock the section by calling the unlock callback.

My brain must be soft, I bet I've been on christmas holidays too long or
something! ;-)

-- 
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com