Re: [PATCH] http.c: don't rewrite the user:passwd string multiple times

From: Daniel Stenberg <daniel@haxx.se>
Date: Jun 19, 2013, 07:40 UTC
Message-ID: <alpine.DEB.2.00.1306190927020.23103@tvnag.unkk.fr>
In-Reply-To: <20130618221327.GA14234@sigill.intra.peff.net>

On Tue, 18 Jun 2013, Jeff King wrote:

Show 6 quoted lines

>> 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