If you are locking around the curl calls you should be ok for most of it then.
We were using https with client certs as well, which I think aggravated the thread safety issue.
Even with a mutext, I think you will still need to disable signalling or else a curl timeout will not work properly.
Without c-ares, there is a possibility that when it goes to dns resolve a curl call, it may never finish and try forever. We experienced this even in the one server only case when the network very temporarily went out during a dns resolve. Things got stuck forever until a filesystem remount. It would not be needed though if you just used the ip address for the call.
From: Alex Andreotti [alex.andreotti@...]
Sent: Thursday, August 29, 2013 6:05 PM
To: Fox, Kevin M; fuse-devel@...
Subject: Re: [fuse-devel] spideyfs
Thank you Kevin,
the project have more than one year but only today (after a major
update (I was using only POST and en/de-code for every w/r with
base64)) I thought to write to the list.
I had some problem with curl and threads when the project started but
there's a mutex already that seem to be enough (mainly around the curl
perform), in the next days anyway I'm going to do some stress test (so
much time is passed that I forgot already how fuse use the threads and
what the problem was, will have to look into again).
I'm not sure to really need/want c-ares (if I understand correctly
what it does) because the requests are mainly to only one address, so
not sure if the benefit worth the effort.
On Thu, Aug 29, 2013 at 01:59:40PM -0700, Fox, Kevin M wrote:
> Oh, one other thing. you probably want to ensure you have c-ares support in libcurl and disable signalling with CURLOPT_NOSIGNAL