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

> > You misunderstand this safety, its simply there to allow code like ::
> >
> > Curl_share_lock()
> > Curl_share_lock()
> >
> > or
> >
> > Curl_share_unlock() /* not previously locked */

I don't see the point in having us support this, as we shall never ever do
this within our own code.

> 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;
> }

Right, since libcurl has no clue at all if this is the same thread or another
thread that is asking. We should not allow multiple locks.

> 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.

I agree.

-- 
 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