I want to take a moment to call out what I think is an interesting part of my previous post. Anonymous delegates have an interesting capability. To illustrate, here’s an example:

using System;
using System.Threading;

class Program
{
    static void Main(string[] args)
    {
        // 'num' lives on the main thread's stack.
        int num = 0;
        Console.WriteLine("initial num=" + num);

        Thread thread = new Thread(
            delegate()
            {
                // Yet this delegate running on a different thread with
                // it's own stack has access to 'num' as well.
                num = 42;
            });

        thread.Start(); // Start the worker thread.
        thread.Join();  // Wait until the worker thread has finished.

        Console.WriteLine("final num=" + num);
    }
}

It’s pretty simple. This program declares and initializes a variable named num, creates and starts a thread that will set num to a different value, then waits for the thread to to complete. In the program’s output we see that num has indeed been set to 42. Here’s the view from the command line:

F:tmp>csc Program.csMicrosoft (R) Visual C# 2005 Compiler version 8.00.50727.42for Microsoft (R) Windows (R) 2005 Framework version 2.0.50727Copyright (C) Microsoft Corporation 2001-2005. All rights reserved.

F:tmp>Program.exeinitial num=0final num=42

Okay, that’s as expected. But wait–num lives on the main thread’s stack. How is it that the second thread we’ve created has access to num? num isn’t on the second thread’s stack and it would be a pretty scary thing if the second thread had direct access to the first thread’s stack. All sorts of mayhem could ensue. Providing access to another thread’s stack isn’t exactly the sort of thing we want to happen in managed code.

Chicanery?

As it turns out, though it appears that num is a stack variable in the main method it is not. What we’re experiencing here is a convenience provided by the compiler. Or rather, a trick. A sleight-of-hand. An illusion. num doesn’t actually live on the stack.

In fact, the compiler has made num a field in a compiler generated class so that it can be made available on the heap to the delegate. Here’s the compiled code, courtesy of .NET Reflector:

[CompilerGenerated]
private sealed class <>c__DisplayClass1
{
      // Methods
      public <>c__DisplayClass1() { }
      public void <main>b__0()
      {
          this.num = 0x2a;
      }

      // Fields
      public int num;
}

The compiler has given our anonymous delegate method a name: it’s <main>b__0() on this compiler generated class. As a member of this class it obviously has access to num. The illusion is completed by fitting out the Main method so that it has an instance of <>c__DisplayClass1 to use:

private static void Main(string[] args)
{
      Program.<>c__DisplayClass1 class1 = new Program.<>c__DisplayClass1();
      class1.num = 0;
      Console.WriteLine("initial num=" + class1.num);

      Thread thread1 = new Thread(new ThreadStart(class1.b__0));
      thread1.Start();
      thread1.Join();

      Console.WriteLine("final num=" + class1.num);
}

So now our Main method has an instance of an object on the heap and can set num to zero since num is a public field on the compiler generated class.

And so, both threads are accessing a variable–not on the stack, but on the heap and accessible to both threads. This helpful behind-the-scenes work by the C# compiler allows us to keep the simplicity of the original code in this example; otherwise, we’d need to implement something like what the compiler has done for us. 

[Edit: Fix up formatting.]

I occasionally find myself writing a .NET console application, usually a one-off program used to test code that I’m working on. C# seems well-disposed to writing such programs. For example, I might need an application to listen for messages from another application, whether over sockets, HTTP, or another protocol–the sort of application that would listen for and process incoming messages, continuing forever. It’s the sort of app you simply run from a console window and when you’re done give it the old Ctrl-C. Just hit Ctrl-C or Ctrl-Break on the console window and the application quickly goes away.  

Now, there’s actually something a little sinister going on here… when the app goes away it’s actually exits rather abruptly. There’s no exception thrown, no catch or finally blocks executed–it just (poof) goes away. This isn’t often a problem for me, but if my program modifies some system state while it’s running and needs to revert that state on exit, well, then it is an issue.  

As a simple example consider a program that logs incoming messages. It may have a file open and log messages as they come in. (Or it could alter a registry setting or some other system state to indicate its presence only to revert that setting on exit. Get the idea?) If the app doesn’t terminate normally, how can it clean up after itself?  

First Try: Simple, but broken

To make this a bit more concrete consider this example code. The tricky bit is that when you press Ctrl-C to terminate the program there is no clean up being done. Specifically, the log file isn’t flushed to disk. When I run this program and hit Ctrl-C the log file is left entirely empty. This is because the program hasn’t written enough to the file to flush the file buffer to disk when the program is interrupted. Remember, this program isn’t exiting normally when we use Ctrl-C to interrupt it. In this case, the text “Handling messages.” never appears in the log.  

using System;
using System.IO;
using System.Threading;

namespace Example
{
   class Program
   {
       static void Main(string[] args)
       {
           try
           {
               using (FileStream fs = new FileStream("sample.log", FileMode.Append, FileAccess.Write, FileShare.None))
               using (StreamWriter logWriter = new StreamWriter(fs))
               {
                   Console.WriteLine(
                       "This is the basic program. It doesn't call the clean-up code if you use Ctrl-C, "
                       + "and the log file isn't flushed to disk.");
                   ProcessIncomingMessages(logWriter);
               }
           }
           finally
           {
               Console.WriteLine("Clean-up code invoked.");
           }
       }

       static void ProcessIncomingMessages(TextWriter writer)
       {
           writer.WriteLine("Handling messages.");
           Thread.Sleep(Timeout.Infinite); // Well, pretend it processes messages, okay?
       }
   }
}

Console.CancelKeyPress Event

As you might guess there is a way to handle Ctrl-C and Ctrl-Break and it’s the Console‘s CancelKeyPress event. By providing a delegate you can have the runtime notify you when a “cancel key” has been pressed. Here I’ve  

• Added an anonymous delegate to clean up if Ctrl-C or Ctrl-Break is pressed. As you can see it flushes the writer and closes the file stream.
• I’ve also moved the fs and logWriter variables outside their using statements to allow access from the finally block.

If you read this code from top-to-bottom it may appear unusual that the code in the CancelKeyPress delegate appears to be using logWriter and fs before either variable is assigned a non-null reference. In fact, what is really happening there is that we’re declaring the code for the delegate in line and handing it off to the CancelKeyPress event–it isn’t executed where its position in the source suggests. In this case it’s only executed when Ctrl-C or Ctrl-Break is pressed.  

        static void Main(string[] args)
       {
           FileStream fs = null;
           StreamWriter logWriter = null;
           try
           {
               Console.WriteLine("This shows use of the cancel handler.");
               Console.CancelKeyPress += delegate
               {
                   Console.WriteLine("Clean-up code invoked in CancelKeyPress handler.");
                   if (logWriter != null)
                       logWriter.Flush();
                   if (fs != null)
                       fs.Close();
                   // The application terminates directly after executing this delegate.
               };

               fs = new FileStream("sample.log", FileMode.Append, FileAccess.Write, FileShare.None);
               logWriter = new StreamWriter(fs);
               ProcessIncomingMessages(logWriter);
           }
           finally
           {
               Console.WriteLine("Clean-up code invoked in finally.");
               if (logWriter != null)
                   logWriter.Flush();
               if (fs != null)
                   fs.Close();
           }
       }

Consolidating Clean Up Code

Here I’ve opted to put the clean-up code in one place rather than duplicating it in the finally block. I’ve declared my own delegate type CleanUpMethod so I have a tidy, parameter-less delegate that I can also call from the finally block.  

       delegate void CleanUpMethod();

       static void Main(string[] args)
       {
           FileStream fs = null;
           StreamWriter logWriter = null;

           string cleanUpLocation = "handler.";
           CleanUpMethod cleanUp =
               delegate
               {
                   Console.WriteLine("Clean-up code invoked in " + cleanUpLocation);
                   if (logWriter != null)
                       logWriter.Flush();
                   if (fs != null)
                       fs.Close();
               };

           try
           {
               Console.WriteLine("This shows use of a single, no-param clean-up handler.");
               Console.CancelKeyPress +=
                   delegate
                   {
                       cleanUp();
                       // The application terminates directly after executing this delegate.
                   };

               fs = new FileStream("sample.log", FileMode.Append, FileAccess.Write, FileShare.None);
               logWriter = new StreamWriter(fs);
               ProcessIncomingMessages(logWriter);
           }
           finally
           {
               cleanUpLocation = "finally.";
               cleanUp();
           }
       }

But why put the clean-up code in a delegate instead of it’s own method? One very helpful aspect of using an anonymous delegate in this example is that the delegate code has access to the local variables in this method. If you use Lutz Roeder’s .NET Reflector to take a look at this program you will see the substantial amount of work that the compiler does for you under the covers in order to provide easy access to the local variables from the delegate method:  

private static void Main(string[] args)
{
     ConsoleCancelEventHandler handler1 = null;
     Program.<>c__DisplayClass3 class1 = new Program.<>c__DisplayClass3();
     class1.fs = null;
     class1.logWriter = null;
     class1.cleanUpLocation = "handler.";
     class1.cleanUp = new Program.CleanUpMethod(class1.b__0);
     try
     {
           Console.WriteLine("This shows use of a single, no-param clean-up handler.");
           if (handler1 == null)
           {
                 handler1 = new ConsoleCancelEventHandler(class1.b__1);
           }

           Console.CancelKeyPress += handler1;
           class1.fs = new FileStream("sample.log", FileMode.Append, FileAccess.Write, FileShare.None);
           class1.logWriter = new StreamWriter(class1.fs);
           Program.ProcessIncomingMessages(class1.logWriter);
     }
     finally
     {
           class1.cleanUpLocation = "finally.";
           class1.cleanUp();
     }
}

I'm pleased the C# compiler does so much work just to make my life easier.  

Technorati tags: .Net, C#, Coding