Updated: 12 July 2015 - It seems that this is all incorrect… Upon running my tests again this morning I find that the x64 task runner also fails to run VS2010 correctly and so the environment differences are unlikely to be the cause…
So, having decided that my continuous integration system could be better, and having looked at JetBrains’ TeamCity and decided that it doesn’t quite fit I’m looking back at some code that I wrote back in 2008 when I last thought about this kind of thing…
I’ve just spent a day tracking down a bug in a pending release of The Server Framework. It was an interesting, and actually quite enjoyable, journey but one that I shouldn’t have had to make. The bug was due to a Windows API call being inserted between the previous API call and the call to GetLastError() to retrieve the error code on failure. The new API call overwrote the previous error value and this confused the error handling code for the previous API call.
Back in September I mentioned that I had found a problem with my usage of Slim reader/writer locks. I expected this to be something that I was doing wrong but it turned out that it was a kernel bug.
This morning Johan Torp tweeted that a hotfix for this issue is now available.
The note on the hotfix states: “Note These issues are not obvious and are difficult to debug. This update is intended for applicable systems to apply proactively in order to increase the reliability of these systems.
As I mentioned back in February I’ve been working on a custom video streaming solution for one of my clients. This has been a lot of fun. It was a nicely defined spec using industry standard protocols developed on a fixed price basis with lots of TDD, what’s not to like.
The system allows a controlling application to set up RTSP streams for broadcasting to multiple clients. The data for the stream is being transmitted live from one of thousands of smart (IoT) devices and the server buffers this and broadcasts it using RTSP to publish the RTP streams.
It looks like the Slim Reader/Writer issue that I wrote about back in September is a kernel bug after all.
Stefan Boberg has just tweeted to let me know that Microsoft has confirmed it’s a bug and that a hot fix is in testing.
I’ve been working on some code for a client recently that needs to run in a multi-threaded environment. Unfortunately it was never really written with that requirement in mind, or, more likely, the people who wrote the code knew that it needed to be accessed from multiple threads but didn’t really understand quite what that meant. As such I’m doing some fairly hairy refactoring for them. It’s high risk as there are no unit tests and the budget doesn’t really extend to completing the work, let alone “spending extra time” writing unit tests… The code is written in quite a ‘C’ style, most things are simple structs and most data is public and as such member functions fall where they are most conveniently written.
This article over on Preshing on Programming looks useful. It gives a step by step guide for building GCC cross-compilers, I expect it will save me lots of time at some point in the future.
I’ve been noticing a strange thing for a while on Windows 8/8.1 and the equivalent server versions. The issue occurs when I’m using a Slim Reader/Writer Lock (SRWL) exclusively in exclusive mode (as a replacement for critical sections). What happens is, when a thread that has just unlocked a SRWL exits cleanly, immediately after unlocking the lock, sometimes threads that are waiting on the lock do not get woken and none of them acquire the lock.
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.
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.
