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

Le Tuesday 07 January 2003 12:15, Sterling Hughes a écrit :
> 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.
>

this situation is normaly managed by the mutex system by itself, so why do we
bother us with all those possible problem? In pthreads (and I'm sure that's
in all others implementation) all those possible problem are taken care of,
it simply return an error. The user just need to return a non-zero value from
the callback and we will return a SHARE_ERROR_LOCKING from the perfrom.

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

I think the best solution is to let this to the user, because we are unable to
know if this is the right thread that lock or unlock the mutex. Trying to do
this is trying to overpass the user implementation of thread, without prior
knowledge of the user implementation.

I think that we must delete all __shared->locked operation, because we are not
in position to exactly know what we are doing.

>
> DISCLAIMER: Message written before coffee was ingested.

- --
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+GxTkb/24YeGNKWQRAnk2AKClvzjqW6/I0eDOHvf4F3+Os6XYTACeNrkm
3NKCnAvMdr8tfgJDK3ALpg8=
=9H3/
-----END PGP SIGNATURE-----

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