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

Sorry, my bad; the actual call to curl_easy_perform() isn't failing...But the results are not as expected.

>
> > 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.

That's what I thought. But I thought maybe curl handled this internally. But after stepping through the code, it appears that it tries to lock the cookie file before modifying it. But there is no share setup, so it immediately returned without acquiring any kind of lock. So now, I've set up a share, and setup the lock and unlock callbacks, passing it a mutex that is acquired when lock is called, and released when unlock is called. So the shared resource is now protected.

>
> > 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?

I guess I would have liked to see a section discussing the calls curl_share_init(), curl_share_setopt(), and curl_share_cleanup(). I had to modify the .def file in order for the API's to be built into the libcurl.dll.

>
> > 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 better docs/examples.
>
> You don't need shares when you use libcurl multi-threaded,
> only if you want the different threads to share resources.

Perhaps this is where my problem lies. I have been using the "easy" interface because it was easy to get started with it. I never use the same curl handle in 2 different threads, and the only place I have a shared resource that curl needs to access is the cookie file. So I think I'm ok as long as I setup the share and have the lock/unlock callbacks to protect it.

>
> > 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 libcurl-the-guide doc.
>
> I hope this made some things clearer!
>

Yes, it does. Thanks very much. I have one last question though. I guess I can look into the code to figure this out, but if you can tell me off hand, that would be great. I've seen that in curl_easy_cleanup(), writing to the cookie file is protected around lock/unlock. I'm assuming the same is done in other places that need to access the cookie file?

Thanks for you help,
Ed

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Received on 2003-09-04