I’ve written an article for Overload, one of the the ACCU’s journals. It’s based on my Efficient Multi-Threading blog post from a few weeks ago. Chris Oldwood mentioned to me about how the object described in Efficient Multi-Threading was similar to an Active Object which steals a calling thread to do its work rather than using one of its own and I agreed, he then suggested that I write it up for the ACCU journal.

Version 6.6.2 of The Server Framework was released today. This release is a bug fix and internal feature release which results in lots of change to the OpenSSL, SChannel, Compression and TCP flow control filters. See the release notes here, for full details of all changes. All clients using earlier versions of both the OpenSSL Option Pack and the SChannel Option Pack are advised to upgrade to this release. Bug fixes:

I don’t believe that UDP should require any flow control in the sending application. After all, it’s unreliable and it should be quite OK for any stage of the route from one peer to another to decide to drop a datagram for any reason. However, it seems that, on Window’s at least, no datagrams will be dropped between the application and the network interface card (NIC) driver, no matter how heavily you load the system.

Performance is always important for users of The Server Framework and I often spend time profiling the code and thinking about ways to improve performance. Hardware has changed considerably since I first designed The Server Framework back in 2001 and some things that worked well enough back then are now serious impediments to further performance gains. That’s not to say that the performance of The Server Framework today is bad, it’s not, it’s just that in some situations and on some hardware it could be even better.

Updated 1st February 2024 to fix broken links There are a couple of undocumented Visual Studio compiler switches which can be useful occasionally: /d1reportSingleClassLayout<name> - which produces a dump of the in memory layout of a given class /d1reportAllClassLayout - which does the same for ALL classes See here and here for more details. And if you liked that, you might find this collection of debugging tricks interesting.

Recently, whilst continuing to improve the performance of various aspects of The Server Framework, I reached a point where I found I needed to replace some STL containers with intrusive containers which didn’t need to perform memory allocations during data insertion and removal. I had been toying with the idea of implementing custom containers for some time but have only recently had a pressing need for them. The STL provides some marvellously usable code which has changed the way people view container classes in C++.

Previously on “Practical Testing”… I’m in the process of replacing STL containers with custom intrusive containers in the timer system that I have been developing in this series of articles. The idea is that the intrusive containers do not require memory operations for insertion or deletion as the book-keeping data required to store the data in the container has been added to the data explicitly. This reduces the potential contention between threads in the application and, hopefully, improves overall performance.

Back in 2004, I wrote a series of articles called “Practical Testing” where I took a piece of complicated multi-threaded code and wrote tests for it. I then rebuild the code from scratch in a test driven development style to show how writing your tests before your code changes how you design your code. Since the original articles there have been several bug fixes and redesigns all of which have been supported by the original unit tests and many of which have led to the development of more tests.

Today I discovered that C++ scoped static initialisation (function level) in Visual Studio is not done in a thread safe manner. It’s the kind of thing that I should have already known but I guess I assumed that since namespace level static initialisation was safe so was function level static initialisation. Unfortunately it’s not. If you read the MSDN documentation in a particular way you could decide that the docs say that it’s not; but it’s imprecise and unclear and I doubt that I did read the MSDN documentation anyway.

I’ve built a small Windows Service which exposes perfmon counters to track sockets in TIME_WAIT state. It can be downloaded from the links later in this post. Back in 2011 I was helping a client look for issues in their systems caused by having too many sockets in a TIME_WAIT state (see here for why this can be a problem). This was affecting their connectivity. Rather surprisingly there seemed to be no way to track the number of sockets in TIME_WAIT using perfmon as there didn’t seem to be a counter exposed.