On Tue, 18 Jun 2013, Jeff King wrote:

But, I don't know if there is any multi-processing happening within the curl library.

I don't think curl does any threading; when we are not inside curl_*_perform, there is no curl code running at all (Daniel can correct me if I'm wrong on that).

Correct, that's true. The default setup of libcurl never uses any threading at all, everything is done using non-blocking calls and state-machines.

There's but a minor exception, so let me describe that case just to be perfectly clear:

When you've build libcurl with the "threaded resolver" backend, libcurl fires up a new thread to resolve host names with during the name resolving phase of a transfer and that thread can then actually continue to run when curl_multi_perform() returns.

That's however very isolated, stricly only for name resolving and there should be no way for an application to mess that up. Nothing of what you've discussed in this thread would affect or harm that thread. The biggest impact it tends to have on applications (that aren't following the API properly or assume a little too much) is that it changes the nature of what file descriptors to wait for slightly during the name resolve phase.

Some Linux distros ship their default libcurl builds using the threaded resolver.


 / daniel.haxx.se
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to