On Sun, Nov 7, 2010 at 10:56 AM, Christian Henning
Hi there,
It would be good if you tried to put the "http://" part in the source. Try "--source=http://www.boost.org/" or "-S http://www.boost.org/".
I just tried it locally and it does require you put a fully qualified HTTP URI -- meaning there should be an 'http://' in the URI.
Thanks, that worked. Cool!
Nice, you're welcome. :)
Can you tell me why the app creates 8 threads? Is there some documentation that explains how threads are being used in netlib?
That's odd, 8 threads? It only creates 2 AFAIK on Linux, one for the reactor thread and one for the thread that handles the completion handlers. Although I do use Boost.Thread shared futures, which may be creating threads of their own -- I haven't checked yet.
BTW, I know I raised the pointed before. But compiling my code takes up to 1.2GB of memory when compiling boost/network/protocol/http.hpp.
Yeah, happens to me to. Imagine how I get any work done while developing it. :D
It also takes almost 3min to crunch. Why is that? Are you trying to create a compiler benchmark? ;-)
Well, to explain a few reasons why, I'd have to point you to the paper I wrote for BoostCon 2010 which I also gave a talk about. [0] In a nutshell: 1. I use Boost.Spirit internally for parsing -- that already exercises the compiler alone. 2. The tag dispatch mechanism used to determine the behavior of the implementation at compile time relies on template metaprogramming. Traits, factories, and selections are done using tag dispatch which relies heavily on Boost.MPL. 3. The amount of code that's already in the library lends itself to using a lot of memory, and especially since everything is a template, that's more time the compiler spends in processing the templates. The code generated then is as efficient as the compiler can make it -- I hide nothing from the optimizer, and all the opportunities for optimization are there. Functions are inlined, loops unrolled, and in some cases operations are vectorized by the compiler's optimizer. I'm trying (hard) to get the compile times down but adding new features to the HTTP server part and later on supporting more overloads to member and free (template) functions will only make the compile time pretty heavy (or heavier, depending on how you look at it). ;) HTH [0] http://goo.gl/3sU8Q -- Dean Michael Berris deanberris.com