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

Le Sunday 05 January 2003 23:34, Sterling Hughes a écrit :
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > (a copy of this message has been sent to libcurl mailing list)
> >
> > I saw in the sharing documentation text
> > (http://curl.haxx.se/dev/sharing.txt) this text:
> >
> > * libcurl guarantees to never lock more than one mutex at any single
> > moment, * from within the same thread.
> >
> > and for respecting this sentence there is this code in the
> > Curl_share_acquire_lock function :
> > - ----------------------
> > if (CURL_SHARE_IS_LOCKED (share, type)) {
> > return SHARE_ERROR_OK;
> > }
> >
> > share->lockfunc (handle, type, share->clientdata);
> > CURL_SHARE_SET_LOCKED (share, type);
> > - --------------------
> >
> > CURL_SHARE_IS_LOCKED is a define:
> > #define CURL_SHARE_IS_LOCKED(__share, __type) ((__share)->locked &
> > (__type))
> >
> > but if I'm not mistaken this thing remove all the locking advantage we
> > are trying to get. The __share->locked variable is not protected by a
> > mutex, so between the moment the locked variable was tested and when the
> > moment we change his value, an another thread may change his value and
> > lock it at the same time that we do it.
> >
> > In the perspective we are giving an API to permit the user to make
> > libcurl thread-safe, it's not our job to verify that the lock is already
> > locked, but the job of the user that suply a mutex mechanism.
> >
> > Anyway when we check if the lock is already locked, our system to check
> > if the lock is locked is not thread-safe, something that we don't want
> > to.
> >
> > I suggest that sentence (the sentence that we are allways sure to not
> > lock 2 times the same lock) is putted away from the implementation, and
> > that we let this thing to the user that want to use his mutex system.
> >
> > (sometimes I will need some english syntax courses...)
>
> You misunderstand this safety, its simply there to allow code like ::
>
> Curl_share_lock()
> Curl_share_lock()
>
> or
>
> Curl_share_unlock() /* not previously locked */
>

okay but in this situation:

thread1 thread2
Curl_share_lock()
(the __shared->locked is set to true)
                                                                Curl_share_lock()
                                                                (this actualy works)

why this is actualy works( in the view of the user of the API)? Because of
this line:
if (CURL_SHARE_IS_LOCKED (share, type)) {
    return SHARE_ERROR_OK;
  }

and this one at the end:
return SHARE_ERROR_OK;

it returns the same value that says: the lock is yours.... But he never REALLY
get the lock: there is 2 thread who thinks that they got the exclusivity of
the lock, but that's false.

it's my opinion that if a user want to do this:

Curl_share_lock();
Curl_share_lock();

in the same thread, he just need set his mutex a recursive mutex type, but
this is not our concern. Anyway a recursive mutex (a thing that you seem to
want to do) need to know who is owning the actual mutex, And we have no
actual possibility to do that.

> Too not do anything harmful. Its not designed for the purposes described
> in your mail (which shouldn't be much of a problem anyway.)
>

It think this is harmful because it permit to thread to have the same lock
acquired, so we are missing all the goal of sharing to make the library
thread safe. With the locking test we are bypassing the goal of all this
mutexs and mutex functions that we give to the API.

> -Sterling
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf

- --
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+Gbi3b/24YeGNKWQRAgSoAKCLIengkxQLOk2FDrUWV/XWTvYebwCfbqUO
S5gI5B7RJfoNPaTYouMLNNo=
=3O6A
-----END PGP SIGNATURE-----

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Received on 2003-01-06