> 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.
>
    ok, that's fine... I just put them in as a
    "might-be-nice-to-have-someday" feature, completely optional, I
    really didn't see much use for them...

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

    That's fine, API wise, I'm quite neutral (although I do prefer the
    other approach slightly, just because of the gained advantage of
    data hiding.)

    -Sterling

> --
> Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/
>
>
>
Received on 2002-01-17