Previously on “Practical Testing”… To deal with some specific usage scenarios of a piece of general purpose code I’m in the process of implementing a timer wheel that matches the interface to the timer queue that I previously developed in this series of articles. Last time I left myself with a failing test. The problem is that setting a new timer on the timer wheel sets a timer that’s relative to the time that timer wheel thinks is ’now’ and the timer wheel’s view of the current time could be slightly behind reality; see the previous entry for a diagram that explains the problem.
Whilst looking through the latest documentation for the AppDomainSetup class I see that you can now specify a new AppDomainManager object for each application domain that you create. This removes the duality of the pre 4.0 AppDomainManager as the manager that you specify when you start the CLR can now deal solely with the requirements of the default application domain and it can set a new AppDomainManager object for each application domain that it creates.
I’m working on some prototype code right now to improve the “deployment characteristics” of a socket server that I wrote for a client which uses CLR hosting to provide multiple managed applications within a single unmanaged host. The client wants to be able to start, stop and restart individual managed applications within the server so that during development or when a managed application is updated they don’t need to restart the whole unmanaged server process to use a new version of a managed application.
I’ve recently been adjusting my CLR hosting code as a client wanted to be able to host the .Net 4.0 runtime. Previously they were hosting the 2.0 runtime and, as I mentioned a while back, the hosting API has changed with 4.0.
Switching to hosting 4.0 was easy enough but being able to fall back to hosting 2.0 on a machine where 4.0 wasn’t installed is slightly more complex. It’s reasonably obvious (you need to make sure that you call GetProcAddress() to bind to CLRCreateInstance() rather than linking to it at build time), but Brad Wilson has a nice list of steps to show how it’s done here on his blog.
One of the problems of having a collection of tools that interoperate is that there’s often a lag between when a tool will interoperate with the latest version of another tool. I’m hardly a bleeding-edge tool junky, I wait until RTM before I start using the latest Visual Studio on a daily basis, and in the case of VC 6 I stuck with it (as did most of my clients) until VS2005 came out and actually improved life for unmanaged C++ development… However, it seems that some tools take a long long time to catch up with Visual Studio.
Previously on “Practical Testing”… To deal with some specific usage scenarios of a piece of general purpose code I’m in the process of implementing a timer wheel that matches the interface to the timer queue that I previously developed in this series of articles. The timer wheel trades space for speed and so far the development has gone well as I’ve been able to use the tests that I had already developed for the previous implementations to guide the new development.
Yesterday I had a bug report from a client who had a user that was getting an exception report from their software which simply said “GetTempPath() - Failed to get temp path”. Now as error messages go this isn’t the best but it comes from some code that has been in my tools libraries for around 10 years and which has never failed before, it has no tests, we’re probably lucky that the message didn’t just read “TODO” as I’m pretty sure that it’s the first time that anyone has ever seen it apart from by reading my source code or running strings on an exe that includes my source code… Anyway…
I’m in the process of implementing a timer wheel that matches the interface to the timer queue that I previously developed in this series of articles. The idea being that for certain specific usage scenarios the timer wheel will perform better than the timer queues. Last time I refactored the tests that I was using for the timer queues to remove duplication and I now have a set of failing tests for the new timer wheel.
The most recent articles in the “Practical Testing” series have been discussing the performance of the timer queue that we have built. Once I had got some new, optional, performance tests in place to measure what we were trying to improve I eventually came up with a new approach and began to implement a timer wheel that conforms to the interface used by the other implementations of my timer queue. Whilst doing this it became obvious that there was duplication in my test code and so the tests have been refactored to remove the duplication of the test code between CCallbackTimerQueue and CCallbackTimerQueueEx and, in addition, to create a full suite of tests for the new CCallbackTimerWheel class.
The most recent articles in the “Practical Testing” series have been discussing the performance of the timer queue that we have built. As I hinted when I first brought up the performance issues, the particular use case that I have which is causing problems might well be more efficiently dealt with using a different (more specialised and less general purpose) design.
The timer queue has adequate performance for general purpose use and can handle timers set within a range of 0ms to 49.
