Peter Bromberg's UnBlog

I like long walks, especially when they are taken by people who annoy me.    - Noel Coward For some time I’ve been working on an ASP.NET web site issue where almost like clockwork, once an hour, the app recycles and then once again about six minutes later, it recycles again. It took a long time to find it, but it turns out that “we’re our own worst enemy”. No, it wasn’t some external process like Task Scheduler on the box, running once per hour and hogging threads. It was me having so much fun doing FireAndForget pattern RPC server pings on every search that I was shooting myself in the foot! This is what happens when we put in some new cool “thing” and then six months later, when we start to see problems, we can’t remember what we did! The ASP.NET “Deadlock detected” shows up in your Application Event log. It’s kind of cryptic, but here’s the general cause: You have a Threadpool per AppDomain. You may have a number of different operations going on (including just servin...

The Microsoft Robotics Studio ( http://msdn.microsoft.com/robotics/ ), which was recently released, has a unique set of assemblies called Concurrency and Coordination Runtime (CCR). The CCR.Core assembly is only 154KB. Unfortunately, the only way you can get it (currently) is to download and install the entire April 2007 CTP: ( http://www.microsoft.com/downloads/details.aspx?FamilyId=71D96DE4-E3D9-496E-B48E-B35697C88FF1&displaylang=en ) -- at 54.3 MB. The central feature of the CCR is that it makes programming asynchronous behavior much simpler than the typical challenge of writing threaded code. When an application's thread performs synchronous I/O requests, the application is giving up control of the thread's processing to the I/O device (a hard drive, a network, etc.). The application's responsiveness then becomes unpredictable. When threads are suspended waiting for I/O requests to complete, the application tends to create more threads in an attempt to accomplish mo...