This is a story about leaky abstractions. It’s not a happy story, and I don’t talk about cool things like WPF, AJAX, JSON, POX, or how much I detest the RIAA.
Instead, this is the story of a developer and the Process.Start() method. It’s not exciting, and I don’t mention Silverlight anywhere other than this sentence.
Still, you should listen.
Leaky Abstractions are the technological equivalent of a spring poking through your couch. Until the day that you sat on that rusty, pointy springy-spring, you knew that your couch was comfy. To tell the truth, you really didn’t know, care, or care to know why. Joel Spolsky has his own diatribe on this subject, and it’s worth reading. Of course, he talks about software, and not couch springs, but I’m sure you will still get the point.
Some time ago, my team noticed that a core part of our application would fail to respond, and when we restarted it, it would fail to reclaim its remoting TCP/IP port. Specifically, it listened on port 30123, and whenever we restarted the application, we would receive a System.Net.Sockets.SocketException claiming that the port was already in use. From the command line, a netstat –a verified this information. The netstat output also revealed that the “dead” process had the port still locked. We were mystified, as netstat was reporting a Process ID (PID) that was no longer in the task list.