On Tue, 2003-01-07 at 05:30, Daniel Stenberg wrote:
> 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.
>

Well, we'll never knowingly do this. The fact is we might very well be
doing this inadvertently. Its going to be a bad thing if we unlock
something that is already 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;
> > }
>
> 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.

I think the best solution to this is to return SHARE_ERROR_AGAIN, or
something similair when calling the lock() function. When calling the
unlock function, then we can call SHARE_ERROR_OK and not worry about it.
-Sterling

DISCLAIMER: Message written before coffee was ingested.

-- 
Sterling Hughes <sterling_at_bumblebury.com>
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com