Every delegate has the inherent ability to be called asynchronously. When a delegate is defined, the compiler creates a new class inheriting from MultiCastDelegate and synthesizes a constructor and 3 methods: The first, and most well known, is Invoke, that accepts the arguments defined in the delegate signature. This is the method called when the delegate is "invoked". Assuming the following:

delegate int BinaryDelegate(int a, int b, out bool overflow);

An instance of the delegate can be invoked like so:

static int InvokeOperation(BinaryDelegate op, int a, int b, out bool overflow) {
    if(op != null)
        return op(a, b, out overflow);

    return 0;
}

Which is actually translated into:

static int InvokeOperation(BinaryDelegate op, int a, int b, out bool overflow) {
    if(op != null)
        return op.Invoke(a, b, out overflow);

    return 0;
}

Synchronous invocation means the current thread executes all methods connected to this delegate sequentially.

A delegate can be invoked asynchronously by calling the BeginInvoke synthesized method. It accepts the delegate defined parameters plus two additional parameters, one of which is a delegate to be called when the operation completes (can be null) and a context user defined value. It returns an implementation of IAsyncResult, common in other asynchronous invocations across the framework.

IAsyncResult is used to identify the invocation and to obtain the result by calling the other synthesized method on the delegate, EndInvoke, which accepts the ref/out parameters and the IAsyncResult instance and returns the type the delegate defines. It can also be used to poll for completion by using the IsCompleted property, or to wait for it to finish by using the AsyncWaitHandle property and calling WaitOne on it. Here's an example, using a completion callback:

void DoSomething() {
    BinaryDelegate del = DoOperation;
    bool overflow;
    IAsyncResult ar = del.BeginInvoke(4, 7, out overflow, OnComplete, del);
}

static void OnComplete(IAsyncResult ar) {
    bool of;
    int result = ((BinaryDelegate) ar.AsyncState).EndInvoke(out of, ar);
    // use result
}

static int DoOperation(int a, int b, out bool of) {
    //...
}

It's a bit awkward to pass the delegate instance to the completion callback - an anonymous delegate can make it much less so:

void DoSomething() {
    BinaryDelegate del = DoOperation;
    bool overflow;
    IAsyncResult ar = del.BeginInvoke(4, 7, out overflow, delegate {
        bool of;
        int result = del.EndInvoke(out of, ar);
        // use result
    }, null);
}

Calling EndInvoke is important for several reasons:

• It's the only way to get back the results, if any.
• It releases the reference the CLR holds to the IAsyncResult object, so it can be garbage collected.
• If the delegate's callback throws an exception, it's swallowed silently by the CLR and re-thrown by EndInvoke.

The only limitation of asynchronous delegates, is that they work only when a single method is connected to the delegate (synchronous invocation works for multi-method delegate instances). I don't really see why this has to be.

• Read more
• No comments

Actually, I have no idea... but here are my suggestions for new features that I think are worth it:

1. Generic Operators

Currently, operators do not work on generic types without some base class constraint that defines those operators. For instance, the following code does not compile:

public static T Sum<T>(IEnumerable<T> data) where T : struct {
   T sum = new T();
   foreach(T i in data)
      sum += i;
   return sum;
}

The reason is that the compiler and the CLR cannot insure all types have the + operator. This is why constraints were invented.

But there is currently no constraint that pertains to operators. One possible syntax may be something like this:

public static T Sum<T>(IEnumerable<T> data) where T : struct,
    T : T operator+(T, T) {
    T sum = new T();
    foreach(T i in data)
        sum += i;
    return sum;
}

.csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; }

but this is awkward (to say the least), as operators can accept any types as arguments, but really unnecessary. The compiler can determine automatically the required constraints based on the usage of the operators themselves. So, the first code snippet should compile and execute fine for any type that implements operator+. What's needed is a way for the compiler and CLR to represent that kind of constraint in the metadata.

2. Generic Specialization

More generic stuff. Currently, a generic type or a generic method cannot be specialized for a specific type. For example, the List<T> class cannot be specialized for (say) List<string> to behave differently, perhaps with string based optimizations or whatever. This is possible in C++ but not in C# (probably because the metadata and CLR do not support this). This could be a nice feature.

3. Multiple Inheritance

Yes, I know the CLR does not support inheriting from multiple types, and for a good reason. Multiple inheritance can create great problems, as evident in C++ (for example) that does support it. Just look at virtual inheritance in C++ and you'll understand why...

I'm not suggesting adding this to the CLR. But multiple inheritance in its simplest form can be implemented by containment and delegation:

class SomeBase { /*...*/ }
class A {
    public void Foo() {
        /*...*/
    }
}

class B : SomeBase {    // normal inheritance
    private A _a = new A();
    public void Foo() {
        _a.Foo();
    }

    public static implicit operator A(B b) {
        return b._a;
    }
}

void UseB() {
    B b = new B();
    b.Foo();

    A a = b;
    a.Foo();
}

This is quite boilerplate, so the compiler can complete this on its own: add a private member of the "inherited" type and automatically delegate, and add an conversion operator. Here's a new suggested syntax:

class B : SomeBase, A {
}

The compiler will insert all the other stuff. The first base specified is the "real" base class.

4. Auto-implemented Interfaces

Sometimes a type implements an interface by delegating it to a member that implements it. For example:

class A : ICollection<string> {
    private readonly List<string> list = new List<string>();

    #region ICollection<string> Members

    public void Add(string item) {
        list.Add(item);
    }
    public void Clear() {
        list.Clear();
    }
    public bool Contains(string item) {
        return list.Contains(item);
    }
    public void CopyTo(string[] array, int arrayIndex) {
        list.CopyTo(array, arrayIndex);
    }
    public int Count {
        get { return list.Count; }
    }
    public bool Remove(string item) {
        return list.Remove(item);
    }
    public bool IsReadOnly {
        get { return ((ICollection<String>)list).IsReadOnly; }
    }
    #endregion

    #region IEnumerable<string> Members

    public IEnumerator<string> GetEnumerator() {
        return list.GetEnumerator();
    }

    #endregion

    #region IEnumerable Members

    System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator() {
        return list.GetEnumerator();
    }

    #endregion
}

.csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; }

This is pretty straightforward, but tedious. I'd like to see something like:

class A : IEnumerable<string> {
    private string List<string> list = new List<string>() : implements IEnumerable<string>;
}

This is my list so far. I may come up with a few more ideas along the way...

• Read more
• 2 comment(s)

Here's an update to the CLR Explorer tool. Improvements in this version are:

• Added a "Types" node under an assembly node. Lists all the types with name, namespace, type (class, interface, struct, enum) and visibility (public or internal). Simple sorting is supported.
• Right-clicking on a thread and selecting "Call Stack..." shows the call stack of that thread (only if it's a managed thread).
• Pressing Tab navigates from the tree view to the list view and back...

Any comments or suggestions are welcome.

• Read more
• 1 comment(s)

In the last few days I created the first version of a tool I call "CLR Explorer". This tool allows viewing live CLR-enabled processes, showing the AppDomains, threads and assemblies in those processes.

The application is similar in look to Windows Explorer, with a tree-like view on the left and a list view on the right. Here's a screen shot:

The tool works by utilizing the native debug interfaces the CLR provides, namely ICorDebug and its derivatives, such as ICorDebugProcess and the like. These are the basis of a CLR based debugger. I have a started an ambitious project to create a "Debugging Studio" (as Sasha Goldshtein calls it), with the power of WinDbg+SOS(ex) and the ease of use of Visual Studio, that can be used in production environments - i.e. no dependency, just a single native EXE.

The CLR Explorer tool is my first attempt at utilizing those interfaces, with sketchy documentation at best, and errors and omissions at the worse end. Wish me luck... if anyone wants to join in and has good knowledge of C++ and COM (and MFC doesn't hurt for the UI stuff) - let me know.

Check out the tool - I plan to put in in OpenUp when I tidy up the code a bit... but for now any comments or suggestions are welcome. I plan to add a few features in the next few days.

The tools refreshes for new processes (this is not supplied automatically with the debug interfaces) and is updated when a process exits, a thread created or destroyed, an appdomain is created or destroyed. More events might follow.

Again, any comments and suggestions are welcome, and if there are serious bugs - let me know too (I know of a few "small" bugs that I intend to correct).

• Read more
• 7 comment(s)

As we all know, the CLR JIT compiles the IL code to the native platform upon first invocation of a method in the current run.

When people hear of the Ngen.Exe tool, that allows compilation to native code - they usually think it's a great idea. So why not use it? No need to JIT compile - the application should start faster. Are there any downsides?

The main downside to using Ngen is the lack of runtime optimizations. Ngen must select some target CPU and compile against it.

When the CLR JIT compiles a method, it can use actual platform knowledge (which can be different than the original where Ngen compiles) to optimize the code (using special instructions, etc.). So, overall, the performance may benefit from JIT compilation because the actual target can be taken into account.

That said, there may be times where Ngen makes sense. It simply needs to be tested on a case by case basis.

• Read more
• 2 comment(s)