-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Tuesday 07 January 2003 05:42, Daniel Stenberg a écrit :
> 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?
>

a read/write system lock is just a structure that use mutex and condition
variable to be able to maximise the time that we can use the protected
variable.

"a read/write lock is a lot like mutex. It is a another way to prevent more
than one thread from modifying shared data at the sane time. But unlike a
mutex it distinguishes between reading data and writing data. A mutex
excludes all other threads, while a read/write lock allows more than one
thread to read the data, as long as none of them needs to change it.

Read/write locks are used to protect information that you need frenquently but
usualy don't need to modify. For example, when you build a cache of recently
accessed information, many threads may simultaneously examine the cache
without conflict. When a thread needs to update the cache, it must have
exclusive access."

this text was took in the Programming with POSIX threads by David R. Butenhof
P. 254.

If we don't use that, or we doen't offer the possibility to do that, there
will be a bottleneck when we will use the global DNS cache.

There's two possible situation: the first it that we make ourself the
read/write lock, the second is that we offer the possibility to the API user
to construct one.

The first possibility goes with 2 new callback options (condition_broadcast
and condition_wait) and two data options ( we'll need 2 condition variable).

The second possibility, the more simple for us, goes with an another parameter
in the mutex callback function. The parameter will be the type of the access
of the global dns cache.

typedef int (*curl_mutex_func)(
        CURL *easy, curl_mutex id, void *clientp
        );

becomes:

typedef int (*curl_mutex_func)(
        CURL *easy, curl_mutex id, void *clientp, int access_type
        );

> 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! ;-)

- --
Jean-Philippe Barrette-LaPierre
Maintener of curlpp: When TRYING(but still in good way) to get the best of C++
(http://www.sourceforge.net/projects/curlpp)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+GwaJb/24YeGNKWQRAm8gAJ0dxhBvFmXF4dLhaiypNRL37ymsaQCdGnI8
LS9itu/NbvKCTH7La5oxPtA=
=H/5/
-----END PGP SIGNATURE-----

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com
Received on 2003-01-07