[cfe-dev] Question on clang design - Why clang doesn't use pooling of Process

David Blaikie dblaikie at gmail.com
Wed Jul 25 09:46:35 PDT 2012


On Wed, Jul 25, 2012 at 4:46 AM, Journeyer J. Joh
<oosaprogrammer at gmail.com> wrote:
> Hello, list
>
> I am reading clang source code.
> And while my reading of it I found that clang as a driver invokes
> another clang as a worker process to convert a input file to the
> output file.
> This method looks weird to me because the driver clang invokes worker
> clang so many times. It would be the number of input source  file!
> This means that 1000 C source code compile would invokes clang 1000 +
> 1 times.
>
> For server programming this kind of work is handled by processpool or
> threadpool.
>
> Pooling invokes process' or threads only a certain times like 10 times
> and with this 10 process of threads tasks are handled with no more
> loading of process load or creating new thread load.

I'm a little confused. Are you suggesting that if you run "clang a.cpp
b.cpp -fsyntax-only" (just to ignore linking & other issues) there are
a total of 3 processes created? The driver and then two separate
frontend actions for a.cpp and b.cpp? That would seem surprising to
me, though I haven't looked at the driver logic carefully - I would
expect it to only create one frontend process for a given driver
execution. And if my model of this is correct, exactly what pooling
would you expect to help here?

>
> This is just my personal question and I believe clang's current
> architecture would have reasonable reasons for every implementations
> of it.
>
> Any answer is welcome ^^; I want to learn from you.
>
> Thank you very much in advance as always.
>
> Cheers!
>
> Journeyer J. Joh
> --
> ----------------------------------------
> Journeyer J. Joh
> o o s a p r o g r a m m e r
> a t
> g m a i l  d o t  c o m
> ----------------------------------------
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev



More information about the cfe-dev mailing list