curl-users
Re: curl cookie jar
Date: Tue, 28 Aug 2001 16:47:50 +0200 (MET DST)
> > On a similar note, we are investigating methods to allow several curl
> > handles (even used by different threads) to share a single cookie list.
> >
> > The solution proposed by me is to create data type curl_cookie_list
> > (with no inherent mutex locking) and have curl call optional functions
> > whenever it wants to access the list:
> >
> > curl_cookie_list clist;
> > /* build initial cookie list somehow */
> > curl_easy_setopt(CURL_COOKIELIST, &clist);
> > curl_easy_setopt(CURL_COOKIELIST_LOCK, lockfunction);
> > curl_easy_setopt(CURL_COOKIELIST_UNLOCK, unlockfunction);
> >
> > curl would call lockfunction whenever it wants to read from the cookie list
> > (if lockfunction != NULL), und unlockfunction afterwards. The same happens
> > whenever curl wants to add a cookie to the list. By default, both function
> > pointers are NULL, and the clist is not thread-safe/shareable. If the
> > application wants a shareable list, it creates a mutex for this list (in
> > whatever thread-system it uses, for example pthreads) and passes functions
> > to (un)lock this mutex to curl - voila, a shareable clist.
> Who provides lockfunction? The caller?
Yes, since only the caller (i.e. the application) knows what thread-system
is in use.
> Does this mean all callers
> would need to implement fcntl-style locking? Seems like a bit much for
> the callers
No, I'm not talking about file-locking, I'm talking about sharing a
cookie-list (in RAM) between several curl-handles used by different
threads - and giving the application a way to manipulate this list
as well.
> Actually, should we even bother with allowing a custom lock function?
Because at Curl's build time, you cannot know what thread-system will be
used by the application - or if the application uses threads at all.
So all you can do is provide callback hooks for Curl to call at runtime.
For example, I have an application that uses Curl as it's engine for
HTTP-access. The application decides at startup whether it wants to be
a single-threaded program using a single curl handle to fetch things
(no locking necessary), or a multi-threaded program with a curl handle
for each thread, fetching things simultaneously. And in the latter case,
I want all the handles to share one global cookie list, with all threads
reading and adding cookies to the list. So I need a locking mechanism
for the list. But I don't want a locking-mechanism built into the cookie
list, because that would unnecessarily slow down the single-threaded case
(and it makes ports to different OSes with other thread-systems difficult).
Regards,
Ingo
-- ECCE TERRAM Internet Services GmbH Ingo Wilken Edewechter Landstr. 42 delta_at_ecce-terram.de 26131 Oldenburg ++49 (0)441/500-12-0Received on 2001-08-28