cURL / Mailing Lists / curl-library / Single Mail


share implementation

From: Jean-Philippe Barrette-LaPierre <>
Date: Sun, 5 Jan 2003 16:54:08 -0500

Hash: SHA1

(a copy of this message has been sent to libcurl mailing list)

I saw in the sharing documentation text (
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);
- --------------------

#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...)
- --
Jean-Philippe Barrette-LaPierre
Maintener of curlpp: When TRYING(but still in good way) to get the best of C++
Version: GnuPG v1.0.7 (GNU/Linux)


This email is sponsored by:ThinkGeek
Welcome to geek heaven.
Received on 2003-01-05