fuzzfork allocating expected number of jobs

[devnexen]

Summary

Instead of pushing a new thread to the list, allocating the number since we know it in advance.

[hans]

Looks okay to me, but maybe expand the comment to explain what's going on and what the patch is doing. "fuzzfork allocating expected number of jobs" sounds more like a bug report than a fix.

[hans]

But was there a bug before, or is this just an optimization? Maybe it could just be an array instead?

[devnexen]

In D71923#1807577, @hans wrote:

But was there a bug before, or is this just an optimization? Maybe it could just be an array instead?

Just optimisation :-)

[hans]

Okay, in that case I would personally just make it an array. But maybe kcc has opinions on this, so let's wait to hear from him.

compiler-rt/lib/fuzzer/FuzzerFork.cpp

void FuzzWithFork(Random &Rand, const FuzzingOptions &Options,
   auto StopJobs = [&]() {
     for (int i = 0; i < NumJobs; i++)
       FuzzQ.Push(nullptr);
     MergeQ.Push(nullptr);
     WriteToFile(Unit({1}), Env.StopFile());
   };
 
   size_t JobId = 1;
-  Vector<std::thread> Threads;
+  Vector<std::thread> Threads(NumJobs);
   for (int t = 0; t < NumJobs; t++) {
-    Threads.push_back(std::thread(WorkerThread, &FuzzQ, &MergeQ));
+    Threads[t] = std::thread(WorkerThread, &FuzzQ, &MergeQ);
     FuzzQ.Push(Env.CreateNewJob(JobId++));
   }
 
   while (true) {
     std::unique_ptr<FuzzJob> Job(MergeQ.Pop());
     if (!Job)
       break;
     ExitCode = Job->ExitCode;