I’ve been working on rewriting the test programme to handle processes, for the position-independent data structures.
Long story short, I’ve taken some of the existing code from test and benchmark, and started again : I’m actually now back to a single libraries, which is both test and benchmark, with a command line convenience wrapper as before (the library has to be there for people running on embedded systems - they don’t have a command line).
I originally wanted a porting abtraction layer library, but it can’t be done, because it’s just too messy to abstract away getting processor topology. To do that you need a topology library, to reduce complexity, and to do that, the porting abstration layer library has to include the main, non-porting library, which makes no sense : a porting abstraction layer should be at the very bottom, independent of everything else. You just can’t emit processor topology info in a clean way though - to do this you need a topology library.
Previously, in test, the test app simply ran one thread on every logical core. One really nice aspect of integrating test and benchmark is that the orthagonal logical processor sets can now be used also to run test, and that if only simple processor info is available (the user implements just say one system node, and then one logical core for each logical core), the benchmark app can still run on that toplogy.
It’s also much easier for the user to compile, and much easier to document.
I originally wanted to have test and benchmark run on threads in one process, then in one thread per process with many processes, then many threads in many processes.
Many threads in many processes turned out to be tricky - it’s not obvious what logical processor sets to compose.
So I backed out of that and now, using the normal logical processor sets, either run them as threads, or as processes.
I then ran into a nasty, messy problem, of starting up processes.
In Linux you fork and it’s great.
In Winodws, Jesus, all you can do is call an external binary. It’s horrific. The only way to communicate with it, without needing another bunch of abstractions (for pipes and so on) is passing it a command line!
I spent today finally getting a passable solution to this, with some abstraction for processes, process sets, command line arguments - oh and command lines are a complete PITA under Windows. In Linux, you pass in an array of pointers to strings. In Windows, you actually have to form up a single long string!
It’s like being in the dark ages.
So, making some progress at last.
I finish my current contract job in nine weeks, at which point I’ll be full time on liblfds until the next release is out (well, barring some time catching up with friends, which will take a week or two).