Question

Consider the following code:

// module level declaration
Socket _client;

void ProcessSocket() {
    _client = GetSocketFromSomewhere();
    using (_client) {
        DoStuff();  // receive and send data

        Close();
    }
}

void Close() {
    _client.Close();
    _client = null;
}

Given that that the code calls the Close() method, which closes the _client socket and sets it to null, while still inside the `using’ block, what exactly happens behind the scenes? Does the socket really get closed? Are there side effects?

P.S. This is using C# 3.0 on the .NET MicroFramework, but I suppose the c#, the language, should function identically. The reason i am asking is that occasionally, very rarely, I run out of sockets (which is a very precious resource on a .NET MF devices).

Answer 1

Dispose will still be called. All you are doing is pointing the variable _client to something else in memory (in this case: null). The object that _client intially referred to will still be disposed at the end of the using statement.

Run this example.

class Program
{
    static Foo foo = null;

    static void Main(string[] args)
    {
        foo = new Foo();

        using (foo)
        {
            SomeAction();
        }

        Console.Read();
    }

    static void SomeAction()
    {
        foo = null;
    }
}

class Foo : IDisposable
{
    #region IDisposable Members

    public void Dispose()
    {
        Console.WriteLine("disposing...");
    }

    #endregion
}

Setting the variable to null is not destroying the object or preventing it from being disposed by the using. All you are doing is changing the reference of the variable, not changing the object originally referenced.

Late edit:

Regarding a discussion from the comments about MSDN’s using reference http://msdn.microsoft.com/en-us/library/yh598w02.aspx and the code in the OP and in my example, I created a simpler version of the code like this.

Foo foo = new Foo();
using (foo)
{
    foo = null;
}

(And, yes, the object still gets disposed.)

You could infer from the link above that the code is being rewritten like this:

Foo foo = new Foo();
{
    try
    {
        foo = null;
    }
    finally
    {
        if (foo != null)
            ((IDisposable)foo).Dispose();
    }
}

Which would not dispose the object, and that does not match the behavior of the code snippet. So I took a look at it through ildasm, and the best I can gather is that the original reference is being copied into a new address in memory. The statement foo = null; applies to the original variable, but the call to .Dispose() is happening on the copied address. So here is a look at how I believe the code is actually being rewritten.

Foo foo = new Foo();
{
    Foo copyOfFoo = foo;
    try
    {
        foo = null;
    }
    finally
    {
        if (copyOfFoo != null)
            ((IDisposable)copyOfFoo).Dispose();
    }
}

For reference, this is what the IL looks like through ildasm.

.method private hidebysig static void  Main() cil managed
{
  .entrypoint
  // Code size       29 (0x1d)
  .maxstack  1
  .locals init ([0] class Foo foo,
           [1] class Foo CS$3$0000)
  IL_0000:  newobj     instance void Foo::.ctor()
  IL_0005:  stloc.0
  IL_0006:  ldloc.0
  IL_0007:  stloc.1
  .try
  {
    IL_0008:  ldnull
    IL_0009:  stloc.0
    IL_000a:  leave.s    IL_0016
  }  // end .try
  finally
  {
    IL_000c:  ldloc.1
    IL_000d:  brfalse.s  IL_0015
    IL_000f:  ldloc.1
    IL_0010:  callvirt   instance void [mscorlib]System.IDisposable::Dispose()
    IL_0015:  endfinally
  }  // end handler
  IL_0016:  call       int32 [mscorlib]System.Console::Read()
  IL_001b:  pop
  IL_001c:  ret
} // end of method Program::Main

I don’t make a living staring at ildasm, so my analysis can be classified as caveat emptor. However, the behavior is what it is.