> On Jul 31, 2015, at 9:41 PM, Ray Satiro via curl-library <curl-library_at_cool.haxx.se> wrote:
>
> Would you find this easier to understand:
>
> *If you are using libcurl from multiple threads or libcurl was built with the threaded resolver option (the default in Windows) then the callback replacement functions must be thread safe.*

Is there a way to programmatically know if the version being used was compiled with the threaded resolver? If not maybe say:

"The callback replacement functions must be thread safe, even if your application is single-threaded; libcurl may create threads at its own discretion (ie, via the threaded resolver)."

None of this became clear to me until I attached to the crashing process via gdb, "set print thread-events on" (in desperation), studied output of "curl-config --features" across Linux distros, downloaded and grepped libcurl sources, and tried to apply some common sense.

> I think an option to disable the threaded resolver at runtime or use the OS malloc routines when they are explicitly overridden is very unlikely and defeats the point.

I don't disagree. I was just throwing that idea out there just to see what would stick.

> The way to solve this issue on your end is either use the OS memory functions or make the replacements thread safe.

Sure. That's good advice, and the former is what I've done.

As an aside, this has been a problem that's plagued me for about 2yrs due to not understanding that libcurl might create threads (and that that feature depends on how it was compiled), so I'm super excited to finally understand what's going on and that y'all are improving the docs to help the next chump that comes along. ;)

<topic change>

Let me ask... for projects that link to libcurl (as opposed to exec-ing the command-line interface), do you find that they try to work with the OS-installed version (ie, dynamically link), or do they include a particular version of libcurl and statically link?

For my little open-source project, I'm trying to decide what's actually best for me. The advantage of dynamically linking is ease of installation for users, but then I have to support much older versions of libcurl, so it makes me wonder if I should statically link. The "thread safety" issues I've had are clearly my fault, but trying to support CentOS/Ubuntu/OSX versions that a) are compiled with different runtime-affecting features, and b) are drastically different versions, makes me sad. The distro problem is not one y'all can control, but I'm just curious what you've seen as the pattern in the world...

Thanks again!

eric
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-08-01