That site I have been working on in semi-secret for the last six or eight months is now live. Here it is:
http://feedeachother.com
Explanations, walkthroughs, etc. can all be found there.
Most of the credit for this thing really goes to Udi Falkson, one of my old Cornell friends who actually had the balls to quit a great job at Yahoo! to work on this full time. The lion’s share of the code is his. I’ve seen it, and trust me, his dried blood and guts are all over this thing. At least I am pretty sure that’s what it is.
Please check it out if you have not already, and add me as a contact. I am very proud of this site—working on something that you personally love and want to use is really satisfying.
People that I would like to thank, some of whom are pretty unlikely to ever notice this unless they google themselves:
- Darrel Herbst, an early adopter and the source of a lot of typically brilliant feedback.
- Katya Bassil, for being the best tester ever. You can thank her for Cute Overload working flawlessly.
- Evan Reiser, for tons of good feedback, visual nitpickery, and for scouring the interweb for competitors.
- Ron Eigen, for general enthusiasm and inviting a million people.
- Rich Hedge, for awesome legal advice.
Here’s a problem:
- You have an application that’s hanging permanently or temporarily.
- The hang does not occur in any synchronization code that you have written yourself.
- You are writing a windows forms application, or any kind of application using COM interop.
Let me present an educated guess as to what is happening. Note to people getting here by googling: there are actually many other reasons this might happen in addition to the one I am going to tell you about. I merely suggest that you spend more time thinking before being led too far down a rabbit hole by what I am about to write. Experience has taught me that people tend to lock on to one internet analysis (say, an unrelated KB article mentioning the same exception text) and waste a lot of time on it. None of the other sites seem to be nice enough to explicitly warn you about your own tendencies—I am, you should thank me.
With those disclaimers, here is my psychic debugging response:
- You are inadvertently calling a method on an STA object created on a different thread.
- That other thread is busy doing something else.
For people that managed (har har) to avoid COM development, or stayed completely in the insulated VB6 world, I will now explain briefly everything you really need to know about threading models in this, our fantastic futuristic age.
Methods on single threaded apartment (STA) objects are synchronized. The object receives all calls to its methods on the thread that owns it. This is achieved by creating a hidden window that receives messages for any calls made on those objects. Multi-threaded apartment (MTA) objects behave more or less like any .NET object you create: calls are not automatically synchronized, and you are responsible for doing any synchronization necessary yourself.
So in order for calls to STA objects to work correctly, the thread that owns them has to be free to run its message loop a sufficient percentage of the time. Running a computationally-intensive process on an STA thread is a great way to hang the other threads in your application, if you are careless or ignorant of where the STA calls are.
If you attach with Windbg and dump out the native stacks (~*k), you will probably see threads in calls to WaitOne that got there through functions named things like “SendReceive” above some interop marshalling code if this is indeed your problem. If you are lucky you might see a function called “GetToSTA,” however, the stacks unfortunately do not always make things that easy.
This is one of those things that I have seen a bunch of times, but seems to be on the radar of an increasingly small number of people. It often takes me longer than it should to figure it out, too. If you are doing any kind of practical Windows development, you still need to understand the basics of STA/MTA. That’s because any development that is “practical” will almost necessarily involve interoperating with old code.
Here’s a related post that I wrote, about how STA objects can result in blocked finalizer threads.
Hey, by the way, the last post is likely to be my last Windows-oriented post for the forseeable future. I have recently quit the financial sector and will be starting a fantastically cool new job here in a few weeks. I no longer have a Windows machine at home at all, so unless I take up Mono, expect a lot of posts that mention emacs from now on. I think this will be for the best, since I’ve been kind of bored and nonplussed with .NET stuff lately, F# notwithstanding.
Giving up on Microsoft development entirely was a little bittersweet until someone showed me XMLScript a week or two ago—clearly, a lot of people in that world are out of their god damned minds. Best of luck writing xhtml-serving web applications defined in xml markup with client script written declaratively in more xml, also exposing xml web services to rich client applications defined largely in XAML, updated automatically as defined in xml configuration files, to those of you lucky enough to get to do this.
