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
