Re: Using options CURLOPT_COOKIEFILE & CURLOPT_COOKIEJAR
Date: Thu, 4 Sep 2003 00:12:04 +0200 (CEST)
On Tue, 2 Sep 2003, Edward Chan wrote:
> However, I find that some times, the http request fails. I noticed that if
> I do not call curl_easy_cleanup(), then all is well. So I started stepping
> into the libcurl code. In url.c, in Curl_close(), it tries to lock the
> cookie file by calling Curl_share_lock(), then write to the file, then
> unlock. However, inside Curl_share_lock(), it fails because there is no
> share set up.
Why does it fail because of this? In my version of the code, it will return
immediately (albeit with an error code but the parent doesn't chek it).
> Do I need to setup a share if I have multiple threads that may be accessing
> the cookie file at the same time?
Oh yes, unless you risk having one of the threads ruining it for the others.
> I didn't see anything in the docs about doing this.
True. I just think it is quite natural that an operation that writes to a
single fixed file name will get pretty weird when done from more than one
thread... Where and how would you have wanted it to appear in the docs?
> But I did find some code under the libtest directory that does this, in
> libtest\lib506.c. The code sets the option, CURLOPT_SHARE, but I didn't
> find this option in the docs. It seems like this is probably required in a
> multithreaded environment, correct?
The share stuff is pretty undocumented and secret, and has only recently
started to become documented. I need help to get it extended with more and
You don't need shares when you use libcurl multi-threaded, only if you want
the different threads to share resources.
> Is there a good resource on the proper usage of cookie files?
Not in regard to this issue, but general cookie stuff is detailed in the
I hope this made some things clearer!
-- Daniel Stenberg -- curl: been grokking URLs since 1998 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sfReceived on 2003-09-04