This is the latest new episode of “Practical Testing” where I write about the most recent changes to some real-world, multithreaded code that I’ve been testing, using and developing for over 20 years. As with most things that I’ve written on this blog over the years, the target audience is future me; if anyone else gets any value from anything then that’s a nice bonus. This set of changes, centre on how we handle shutting the timer system down.

This is the next in a series of blog posts, called “Practical Testing”, about testing real-world, multithreaded, code. Code that is in use for a long time goes through various evolutionary changes. The code that we feature in this series of articles is often the beating heart of server systems that are built with The Server Framework. Our many clients have varying performance requirements and changes for one client eventually feed back into the framework that is used by all of our clients.

Back in 2004 I started a series of blog posts, called “Practical Testing”, about testing real-world, multi-threaded code. In 2023 I did a brief precis of how we got here and, since the code is still in regular use and still evolving, it’s time to talk about some of the recent changes. This release of the code makes no functional changes to the code that we’re testing in this series of articles.

Today marks the start of the 30th year of JetByte Limited. Where did the time go? We started as a ‘bum on seat’ contracting company so that Len could work for Credit Suisse Financial Products as a C++ developer back in 1997. This worked well, with interesting work, interesting people and lots of new skills to learn. When UK tax rules were changed we adjusted our working practices as the market changed and this turned out to be the best thing that could ever have happened.

Another year, 2026. We had an exciting 2025, with lots of interesting work on complicated projects. Our focus remains the same as ever, helping clients with high performance, reliable, server systems on Windows and Linux. This year we will begin our 30th year of software development consultancy and, it seems that the more things change, the more they stay the same. The highlight of the year was probably Phase 2 of our server development for our large, American postal company.

A few days ago one of my build machines started to have unexpected test failures during regular integration builds of one of my client’s codebases. My other build machines ran the tests fine and the failures were intermittent and spread over a worryingly large array of tests. TL;DR Don’t use CLOCK_REALTIME to measure wait or delay times as it can be changed and the time reported can move unexpectedly; absolute timeouts do not play nicely with this clock.

I have been using a home-grown continuous integration system based on a hacked version of CruiseControl.Net since 2007. Whilst it’s not perfect, it works, and I have quite a bit of custom tooling that builds configurations for it for various client projects and builds of various versions of The Server Framework. TL;DR By exporting the configuration of Visual Studio as a vsconfig file you can create a custom installation with specific tools in a stand-alone directory structure that can be referenced by build tools, and you can then link specific revisions of code to specific versions of Visual Studio so that they ‘always build’, even if the installed compiler is incompatible.

We’re pleased to have resumed work with our nameless, large, American postal company, who, back in 2019 took our mail-sorting server software into an extended pilot programme. Things went well, they have over 300 servers running the software and are processing over 554 million pieces of mail a day, each one of which results in multiple messages processed by our server software. They now want us to fix a couple of issues and extend the system to support TLS.

I’ve been playing around with the low-level access to the Windows networking stack that is provided by \Device\Afd. This provides a ‘readiness’ interface rather than the ‘completion’ interface provided by traditional IOCP designs. I’ve been meaning to do some comparative performance tests, much in the same way that I did for my investigations of the RIO API, but I’ve been too busy. Instead, what has happened is that the AFD code has made its way into the version of The Server Framework that I’m using with my Online Game Company client.

Welcome to 2025. 2024 was a good year for us, we continued to work with the secretive Online Gaming Company adding to and improving the cloud gaming server that we wrote for them. It’s quite nice to have a client that uses our server code to support over 1.4 billion monthly players and to continue to extend and improve the code that we’ve now been a part of for over 16 years.