This is "whatever arbitrary value I want to use right now" until I get a better unit test framework for this. The eventual goal will be to test scalability by starting at 1 thread and moving up one at a time to 64 threads and verify throughput goes up at least up to hardware_concurrency(). These unit tests are kind of hacky right now so I need to rework them entirely.

This is a stop-gap measure anyway. This class is going to be reworked so that there's a set number of instances of it (one for each power of 2 up to 2048) and they're all instantiated in a cpp file, and the pool allocator will always initialize to the one with the closest power of 2 to the amount requested, so initialization order won't be an issue. And anything larger than 2048 will be serviced directly by mmap/VirtualAlloc. And with that I can write a general allocator that can pick the right pool allocator based on a size passed to it at runtime and all will be happy gilmore.

This class has been removed in the most recent review, so flaws with it don't matter. But I wanted access to a raw pointer, not a reference, so I broke convention to suit my use case.

Also this ASSERT_FALSE() is explicitly testing that there's nothing in the queue. The value of i is never read and never initialized in this case but it doesn't matter; the thing that matters is that the return value is false (meaning it could not dequeue and i was not touched)

Performance tests are flaky. I don't want to leave them enabled on the build machine but I'm leaving them here for my own reference while I'm working on it. They're never going to be 100% reliable because scheduling and any number of things can cause abnormalities in performance results.

They're there so I can easily disable them when I'm focusing on debugging just one test. Without having to edit project files each time to change the --gtest_filter. They're for my conveninece and I'll get rid of them some day, but not right now.

I may be wrong on this. But I think python 3 could just create this as b"▴ Output ▴" instead of making str and the converting to bytes. Though that may not simplify anything here.

I think we really need to make a utility function somewhere to take str input and output str in python2 and bytes in python3 instead of boilerplating this everywhere.

...shouldn't this be "extend(libraryDirs)"? Cause this will just add each character in the library name to the list...

......and you could shortcut that by appendLibDirs = list(libraryDirs)

I'm not saying call it fewer times, I'm saying decrease code deduplication by having csbuild call it itself instead of repeating this same pattern over and over in every toolchain.

We should really hoist the call to setupForProject into the core logic since it keeps getting repeated so often.

Actually, I take that back. All these setupForProject things should be toolchain postPrepareBuild steps.