Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

RFC: Change to how system header threads are started

<< < (2/2)

ollydbg:

--- Quote from: oBFusCATed on October 07, 2018, 01:39:32 pm ---It turns out that the code related to the system headers thread management is really strange. For some strange reason new threads are created but not started immediately. They are only started after the normal parsing stage is done. But I don't understand why! Can someone explain why the code is written in this manner?

--- End quote ---
The name "system header thread" is quite bad, and I suggest a better name like: "header file crawler".

This part of code is independent of the normal parsing code. It just does what a file crawler does, that is collecting header files under user defined include search paths or compiler predefined include search paths.

The code is contributed by our developer Loaden(he is not active right now) several years ago. The reason those threads are started only AFTER the normal parsing stage done is that we don't want to cost CPU to much when we are in normal parsing stage. Since normal parsing stage are running thread tasks from a thread pool, thus, Loaden just deferred the header file crawler until the normal parsing stage is done.

Hope that helps.  :)

oBFusCATed:
Aren't we parsing source code in a single thread at the moment? Or is it a thread per project/parser?

MortenMacFly:
Just for you notice: Seems to work so far on Windows without issues. I also don't see any significant delays, but I have a SSD that the crawler scans. So this might experience be biased.

oBFusCATed:
I don't think we'll see performance regressions from this. Probably on very slow machines, but they would be just slow anyway. On the contrary I think the list of includes would be available a lot sooner...

Navigation

[0] Message Index

[*] Previous page