I’ve just stumbled on these blog posts, by Maciej Sinilo, a game developer. He’s written a memory allocation monitoring tool and mentions that using RtlCaptureStackBackTrace() is a faster (if undocumented) way to capture a call stack. This is interesting to me as the call stack capture code in my debugging tools (deadlock detection, timeshifter, tickshifter, etc.) is pretty slow when using StackWalk64(). It’s also interesting that he seems to store and sort stacks by CRC which is similar to what I do in my tools.
I’ve had a few questions from users and potential users of The Server Framework about how it compares to other available frameworks. One such framework is ASIO.
The first thing to realise is that The Server Framework and ASIO are very different both in design and functionality. ASIO’s strengths are that it’s cross platform, it provides low-level asynchronous I/O and that it uses a modern C++ design (i.e. lots and lots of templates and ‘interesting’ call stacks).
I’m currently writing and testing a simple class that watches for system time changes. This is to allow an app to adjust some timers that it sets for absolute times in the future if the system time changes.
The code’s fairly simple. The system automatically broadcasts a WM_TIMECHANGE message to all top level windows whenever something adjusts the system time or the time zone so all you need to do is write code that creates a hidden window and deals with the message.
I’m in the process of adjusting the asynchronous file log that we use in some of our servers. The log works well and write performance is good for a variety of reasons that I deal with here. The current changes are mainly due to the fact that we have some clients who want to automatically create a new log file every so often whilst the server is running. This hasn’t been a requirement before because most of our servers don’t continually spew out log data.
I’m working on some client code today and it’s fairly typical of most ‘Visual Studio Wizard generated code’ in that it uses precompiled headers in a pretty poor way. The default wizard generated code seems to encourage people down a slippery slope of just including everything in stdafx.cpp and not worrying about the consequences. Of course, by the time the project is large enough for this to be a problem the damage is already done and it’s a nightmare to try and unpick the resulting problems.
One of the questions that comes up time and again from users of The Server Framework is “How to I access the list of current connections within the framework”. My answer is, you don’t, you build your own collection and manage it yourself. Usually these people want to write some form of chat or gateway server; client A connects to the server and needs to send data to client B who is also connected to the server.
There’s an interesting post over on “Blogging Considered Harmful” about why flaming someone for incorrect technical spouting is a good thing; I tend to agree. I actually WANT people to shout down my stupidity, if they’re right and I’m wrong then hopefully I’ll learn from the exchange. If I’m right and they’re wrong then perhaps they’ll learn from it. Either way it should make both sides think; though perhaps I’m being a little naive…
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.
There’s a nice post by Miško Hevery over on the Google Testing Blog about Writing Testable Code. It pretty much sums up my views on testable code. Go read it!
There’s an interesting article over on Dr. Dobb’s about why writing lock free code is so hard. Herb Sutter takes some code from an article that Dr. Dobb’s published a couple of months ago and pulls it apart and points out the problems.
