On Mon, 14 Jan 2002, Sterling Hughes wrote:

Oops, I forgot to post this the other day. Well, I post it now instead! ;-)
I've ripped out this particular thread. Others will be replied to in separate
mails.

> yep, I've attached a rough implementation of this (very simple)
> functionality/api...

I agree with the general approach, but I suggest that we change it slightly.
Considering that a programmer who would like to use libcurl with this mutex
stuff would need to specify several of these function pointers, I would
suggest that the application allocates and inits the 'curl_mutex' struct and
passes that to libcurl with only one single curl_easy_setopt() call.

I think the mutex function calls should be allowed to make a difference
regarding which resource they protect. Using a single mutex for protecting
several different resources is not performance effective, and by passing on
an identifier we let the application make a choice: have one mutex for
everything or have one for each "mutex-needed area" libcurl defines.

I can't see what the 'init' and 'dtor' function calls would be used for by
libcurl. I think they only make things slightly more complex. The application
can setup the mutex code before libcurl is used and it can clean it up when
libcurl is done.

I suggest this 'curl_mutex' struct:

struct curl_mutex {
  int mutex_version; /* CURL_MUTEX_VERSION_1 for this version */
  void *client_pointer; /* whatever you want passed to the callbacks */

  int (*lock)(void *client_pointer, curl_mutex_id id);
  int (*unlock)(void *client_pointer, curl_mutex_id id);
};

And to make libcurl use your mutex functions set in a struct like this, you'd
use a call like:

 curl_easy_setopt(handle, CURLOPT_MUTEX_SET, (struct curl_mutex *)&mutex);

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/