Category Archives: C#

Forwarding events in C#

For a long time I’ve had a problem with events in C#: I want to wrap one class in another, which offers a higher level of abstraction, but this means that all the events have to be copied and lots of boilerplate code has to be written to do the forwarding. The obvious thing to do would be to have an event exposed as a property, which would give clients of the abstract interface read-only access to the event:

public class HigherLevelClass
{
   public event SomeDelegate MyEvent
   {
      get { return impl.MyEvent; }
   };

   private LowerLevelClass impl;

   /* ... */
}

Unfortunately this isn’t valid syntax, and at first glance that seems to be the end of it. However, I discovered today that the designers of C# have actually thought of this, and provided a way round it:

public class HigherLevelClass
{
   public event SomeDelegate MyEvent
   {
      add { impl.MyEvent += value; }
      remove { impl.MyEvent -= value; }
   };
}

Simple, once you know how. But this illustrates an interesting problem with keyword search when applied to programming techniques: I’ve searched for just this information on several occasions, but wasn’t able to find it until I hit on the magic phrase “event forwarding”. In my experience it’s pretty common to know how to describe what you’d like something to do, but not be able to find the same words as the person who knows how to do it.

I’m sure this is far from the only reason, but perhaps it goes some way to explaining why there are eight separate implementations of every single open source library type, each of which is partially complete.

Coroutines in C#

I was excited when I learned about yield return in C#, but my excitement quickly waned when I discovered how closely bound it was to the IEnumerable<> paradigm. In my view, it was a missed opportunity to implement a more general coroutine infrastructure, and have IEnumerable<> implemented on top of that. All the hard work of thinking about coroutine implementation has to be done in order to support enumeration, but the benefit is limited to one case—or so I thought.

The other day I came across a real-world case where I wanted some sort of coroutine support. I was writing a long-running process as a Windows service. Separation of concerns meant that there was a service layer that knew about the logic of when to quit, and an implementation layer that didn’t know anything about the environment it was running in. The problem with services is that they need to be fairly responsive to quitting messages, or you get ugly hangs when you attempt to shut the service down.

The business logic needed a fair amount of setup and teardown, so it didn’t make sense for control to leave this code (and lose the state) unless it was fairly certain that a shutdown was imminent. Potentially I could use a callback delegate here, but to me it felt like a coroutine would be a more natural fit.

So we define our inner loop like this:

void DoSomeWork()
{
   while (HaveWorkToDo())
   {
      Work someWork = GetLargeBatchOfWork();

      while (Job nextJob = someWork.GetNextJob())
      {
         DoJob(nextJob);
      }
   }
}

How to get yield return into this? Apart from anything else, we have to decide what type to return. If I was doing an infinite iteration, there’s probably no information that needs to be returned to the caller, so it could return a single value of any type. Boolean true would do the job, or just an instance of an anonymous local class if you’re worried that the caller will read some significance into the boolean. As it was, I had a task that was long-running but not infinite, so it seemed sensible to return a value that indicated this. I created an enumerated type with values Incomplete and Complete.

We can then do something like this for the inner loop:

IEnumerable<Status> DoSomeWork()
{
   while (HaveWorkToDo())
   {
      Work someWork = GetLargeBatchOfWork();

      while (Job nextJob = someWork.GetNextJob())
      {
         DoJob(nextJob);
         yield return Status.Incomplete;
      }
   }

   yield return Status.Complete;
}

In the main loop this can be read in a fairly natural way:

IEnumerable<Status> worker = DoSomeWork();

while (!TerminateNow && worker.Current == Status.Incomplete)
{
   worker.MoveNext();
}

Is this a massive subversion of how yield return is supposed to be used? It looks quite neat to me, though it needs some commenting to explain what’s going on.  I don’t like the way we have to call MoveNext()—nothing is being moved, as such, so the method name doesn’t communicate as much to the reader as it ought to. I’m also concerned that many developers have yet to embrace the lazy nature of IEnumerable<> and may see a function returning IEnumerable<> as a sign that it’s a long-running function that returns when it’s done.

It’s nice to see that this kind of thing can be done, and that the language isn’t constraining me too much. On the other hand, I still wish I had the control to improve the naming, if nothing else.

Closures in the real world: Part 3

After I wrote my last post about closures, I was fairly clear about how a closure can extend the lifetime of an apparent stack variable:
Closures

What looks like a stack variable isn’t actually a stack variable, it’s an implicit reference to a member variable on an implicitly-defined class representing the closure.

But then another question occurred to me. Closures can extend the lifetime of an otherwise stack-local value type because the value itself lives in the closure and is referenced in the local stack frame. But what if the same variable is referenced in two different closures? Which closure object gets to own the variable, and which gets a reference?

Consider the following example (the same principle applies to my previous example, but this makes the point clearer):

class Program
{
   private static Func<int> MakeAClosure()
   {
      int x = 0;

      Func<int> incrementByOne =
         delegate()
         {
            x += 1;
            return x;
         };

      Func<int> incrementBySix =
         delegate()
         {
            x += 6;
            return x;
         };

      Random rnd = new Random();
      if ((rnd.Next() % 2) == 0)
      {
         return incrementByOne;
      }
      else
      {
         return incrementBySix;
      }
   }

   static void Main(string[] args)
   {
      Func<int> myFunc = MakeAClosure();

      for (int i = 0; i < 10; i++)
      {
         Console.WriteLine("{0}", myFunc());
      }
   }
 }

In this case, two closures are constructed. The apparent stack variable x is not a stack variable, but a reference into one of the closure objects. But which one? The compiler doesn’t know which closure will be returned until runtime, and in any case changes made in one closure (or on the “stack”) ought to affect the other closure.

This diagram shows how things worked in my head, and illustrates the problem:

Closures2

Fortunately, you can see what’s really happening without too much digging into the disassembly:

disassembly

The ugly naming doesn’t help, but note that within the Program class there is a nested class <>c__DisplayClass2.  As we saw before, this is the way that closures are implemented. However, the crucial thing is that there’s only one class at work here, and it holds both closure functions within it (they are the functions called <MakeAClosure>b__x). The fact that we’re returning one of a possible two different closures is actually an illusion: whatever return condition happens we return the entire class and both closure functions. Presumably we somehow also return some sort of reference indicating which of the functions to call when the closure is dereferenced later.