> I have made a few simple changes to allow uses of libcurl in a
> multithreading environment. Let me know if this is a reasonable approach.

You will get the same results by using CURLOPT_NOSIGNAL, which is the
documented approach to use libcurl multithreaded (on unix-like systems).

> Changes assume the use of pthreads: suitable OS specific macros should be
> defined to handle other cases.

We must not make it a compile-time option and we must not make anything in
libcurl assume any threading system/API/style/whatever. You're of course free
to do whatever you want with your copy, but I can't have that added to the
main sources.

Without signals and no ares, you won't be able to abort slow name resolves.
You need to use ares then. Which is one of the main reasons we added support
for it.