Mark Burton <markb@ordern.com> writes:
Is the default for your patch to not become parallel? It seems that making mkgmap parallel is hard, and my personal utility function places correct behavior very high and speed not that much. Until the code is really shaken out, I don't want to run parallel. I don't know what others think, but just a thought.
At this time, it defaults to creating as many threads as there are cores. I don't have a big issue with making the default number of threads = 1 if that's what people want.
How about this:
1 - with no option specified, the default number of jobs (aka threads) is 1.
2 - specifying --max-jobs without a value will maximise the number of jobs (i.e. create one thread per core).
3 - specifying --max-jobs=N will create N threads.
Would that suit you?
That sounds great. I think it would be reasonable to change the default to #2 after enough time has passed that we are really sure that there are no problems from running in parallel. Perhaps there could be a regression test to compare the output from parallel and non-parallel runs. I'm not sure if they are meant to be bit-for-bit identical, or if not if you can articulate the allowable differences. This might require code to parse a .img into canonical form for semantic diffing, but that's probably a useful thing to have anyway.