2023 was a good year. We finished off a project for our Industrial Control Client and everyone seems happy, which is always nice. Our work with the secretive Online Gaming Company is taking up most of our time as we continue to enhance the cloud gaming server that we wrote for them. They continue to go from strength to strength, which is good. We have been rolling out a series of changes into their live environment and increasing test coverage and our ability to test and debug using light-weight journals of communication sessions.

We’ve now reached the end of the recent embedded development project for our Industrial Control Client. The final phase was made more complicated by the difficulty in debugging the changes. The embedded hardware had no screen, and the network debug facility that it supported was unreliable; it sometimes just lost messages. So the first step was to work around this issue with some debug messages in-line with the normal TCP/IP data channel from the hardware.

I had an internet outage this morning. This shouldn’t have been much of a problem for me as all of the code that I needed to be working on is on my local git server and all of the dependencies are local. Or so I thought. The client has a c# shim layer that builds as part of the C++ server build. They rely on NuGet to grab some components from somewhere for some reason.

The second of our “reanimation” projects has reached a significant milestone. We ran the whole new system on the real hardware last week, and it mostly works. This is a big step for us and the client as the project has been quite complex in terms of how the development has been done. As I said, our secret Industrial Control Client has had us working on a program that compiles in Visual C++ 6 on an XP VM.

When your machine has multiple NUMA nodes it’s often useful to restrict a process to using just one for performance reasons. It’s sometimes hard to fully utilize multiple NUMA nodes and, if you get it wrong, it can cost in performance as the nodes need to keep their caches consistent and potentially access memory over a slower link than the memory that is closer to the node, these things can be relatively expensive.

We recently had an old client contact us with an unusual request. We last worked with VEXIS Systems Inc. back in 2010 when we extended the telephony server we’d built for them to support CLR hosting, using The Server Framework’s CLR Hosting Option. We then built a managed plugin system that integrated with the existing unmanaged system so that they could write their business logic in either unmanaged code or in a managed language such as C#.

I’ve always found testing multi-threaded code in C++ a humbling experience. It’s just so easy to make stupid mistakes and for those mistakes to lurk in code until the circumstances are just right for them to show themselves. This weekend a unit test that has run thousands of times for many years started to fail. The reason for the failure was a fairly obvious race condition in the test code. This issue had lain dormant and only been exposed by running the tests on my new development machine.

I’ve had a sick PC for several weeks now. It has cost me a surprising amount of time and thought. It started with my main work machine randomly hanging. This is Windows 11 with a Ryzen 9 5900X, and it has previously run faultlessly for two years or so. The hangs were, at first, annoying and I assumed that it was some driver that had been updated and was playing up, and initially I hoped that it would just fix itself with another update.

Previously published This article was previously published on len-learns-rust.com. A full index of these articles can be found here. In addition to managing the lifetimes of references to variables, the Rust compiler’s borrow checker also deals with enforcing Rust’s guarantees about mutability and so helps to prevent data races. Basically, you can have any number of immutable references to a variable, but only if there are no mutable references to it at the same time, and you can only ever have a single mutable reference.

Previously published This article was previously published on len-learns-rust.com. A full index of these articles can be found here. One of the jobs of the Rust compiler’s “borrow checker” is to track the life of each reference to a variable so that it can prevent dangling references. To do this, it annotates each variable and reference with details of the scope in which it is valid. This annotation is called a lifetime.