> > Moin,
> >
> > Sonntag, 13. Januar 2002 12:37,Daniel Stenberg:
> > > * Mutexing
> > ...
> > >
> > > Instead, I suggest that we have libcurl call two application specified
> > > callbacks for retrieving and releasing mutexes, leaving the actual
> > > implementation for the outside to decide.
> > >
> > > Comments?
> >
> > We (idea from Ingo Wilken, implemted by me) are using this solution some
> > month. We are using libcurl for browser simulation. One day we needed
> > cookie support in our threaded application so we added mutexing right
> > the way you described above.
> >
> > See attached (old) patch. Maybe i will build a patch for 7.9.2 comming
> > week.
> >
> It would actually have to be abstracted a bit, this mutex stuff
> shouldn't be only cookie related, it should be a general function,
> that could be called anytime something should be mutexed (and it
> should have a default function), something so that in the API you
> could go:
>
> Curl_mutex_create(&data);
> // .. Use globals
> Curl_mutex_free(&data);
>

    Just to give a better idea of what I was talking about, I've created
    a small implementation (which should be fully functional), that
    implements the mutex functionality in a more "generalized" manner,
    it also provides support for ::

    Mutex Initialization (Curl_mutex_initialize), Mutex destruction
    (Curl_mutex_destroy), Mutex Locking (Curl_mutex_lock) and Mutex
    unlocking (Curl_mutex_unlock), attached is the patch, and the two
    added files, thread.c and thread.h which should be placed into the
    lib directory. Apply the patch in the base cURL directory.

    Compilation is so far the only thing verified, but it should be
    pretty straightforward.

    -Sterling
Received on 2002-01-14