curl-library
Re: share implementation
Date: Tue, 7 Jan 2003 11:30:30 +0100 (MET)
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.comReceived on 2003-01-07