Over the past few episodes of “Practical Testing” I’ve been implementing some changes to the real-world, multi-threaded code that I’ve been testing, using and developing for over 20 years. These changes have been to enable controlled shutdown. The changes have been designed, stubbed out, unit tests written and then the changes were implemented in one of the two timer systems, the timer wheel. In this, the final episode in this set of changes, we implement the changes in the timer queue.

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. Now that we have sorted out the design for how we will manage the concept of shutting down the timer system we “just” have to implement it. We’ll start by doing the required work for the timer wheel implementation.

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.