Multithread parsing of the gcno and gcda files

Note: It is highly recommended that issue be not worked on at the same time as 
issue 162. The merge would be insane...

This would require minor changes to the spirit parser framework, however would 
require a decent amount of changes to the data structure that stores all the 
information. 

Forseen changes:
1) Spirit framework - easy
  The only place where changes are required are within the primitives, where we use global variables. We'll have to make them thread specific global variables.

2) Parser class - easy
  The parse function will have to fork or grab threads from a pool to work on a single "parse job", which is one gcno and gcda file pair at a time.

3) Parser Data structure - headache
  The data structure will have to be thread safe, but only during construction??? I'm not sure if we ever actually modify the data structure after construction and normalization. If so, then we'll only have to do locking during construction, and just bypass it afterwards. The headache comes from ensuring the appropriate parts of the data structure are locked and unlocked at the appropriate times, and optimized...

Files Affected (new and old)
prims.h
gcno_grammar.h
gcda_grammar.h
common_actors.h
parser_builder.h 
parser_builder.cpp
record.h
record.cpp
...

Input or feedback is highly desired on this one. Thanks

Original issue reported on code.google.com by millerlyte87@gmail.com on 13 Sep 2010 at 1:08

I can only profile the application's CPU time, which is deceiving when the 
application does a bit of file IO.  Running `time trucov list` shows numbers 
that are almost completely CPU bound.  That means in theory you could double 
the performance on a dual core machine.

However, running 'time trucov report` usually much more IO bound.  Writing the 
results files one at a time is slow.  Instead they should be written 
concurrently.  That could be theading, nonblocking IO, or async IO.  This would 
be a pretty easy win as most of the internal data structures are constant when 
the output is generated.

However, for me at least trucov seems plenty fast enough.  My unit tests take 
several seconds to run.  Waiting one more second for trucov output has minimal 
impact.

Either way I suggest making a branch and doing the work there.  I can help with 
that if you're not familiar with mercurial.

Original comment by j.nick.terry@gmail.com on 16 Sep 2010 at 10:13

mavak / trucov

Multithread parsing of the gcno and gcda files #169