views:

119

answers:

4

In what circumstances would updating a UI control from a non-UI thread could cause the processes' handles to continually increase, when using a delegate and .InvokeRequired?

For example:

public delegate void DelegateUIUpdate();
private void UIUpdate()
{
    if (someControl.InvokeRequired)
    {
        someControl.Invoke(new DelegateUIUpdate(UIUpdate));
        return;
    }
    // do something with someControl
}

When this is called in a loop or on timer intervals, the handles for the program consistently increase.

EDIT:

If the above is commented out and amended as such:

public delegate void DelegateUIUpdate();
private void UIUpdate()
{
    //if (someControl.InvokeRequired)
    //{
    //   someControl.Invoke(new DelegateUIUpdate(UIUpdate));
    //    return;
    //}
    CheckForIllegalCrossThreadCalls = false;
    // do something with someControl
}

...then the handles stop incrementing, however I don't want to allow cross thread calls, of course.

EDIT 2:

Here is a sample that shows the handles increase:

Thread thread;
private delegate void UpdateGUI();
bool UpdateTheGui = false;

public Form1()
{
    InitializeComponent();

    thread = new Thread(new ThreadStart(MyThreadLoop));
    thread.Start();
}

private void MyThreadLoop()
{
    while (true)
    {
        Thread.Sleep(500);
        if (UpdateTheGui)
        {
            UpdateTheGui = false;
            UpdateTheGuiNow();
        }
    }
}

private void UpdateTheGuiNow()
{
    if (label1.InvokeRequired)
    {
        label1.Invoke(new UpdateGUI(UpdateTheGuiNow));
        return;
    }

    label1.Text = DateTime.Now.ToString("MM-dd-yyyy HH:mm:ss");
    label2.Text = DateTime.Now.ToString("MM-dd-yyyy HH:mm:ss");
    label3.Text = DateTime.Now.ToString("MM-dd-yyyy HH:mm:ss");
}

private void btnInvoke_Click(object sender, EventArgs e)
{
    UpdateTheGui = true;
}
A: 

This is the standard pattern for using Invoke to marshall updates to the UI thread.

Are you sure your problem is not being caused by other code in your application that is not included in your question?

Justin Ethier
Not entirely sure, but see the edit to the question and also the comment to Hans' answer. It's a very unusual problem.
JYelton
A: 

I don't think it is related. Perhaps just waiting for the garbage collector to dispose the newly allocated object(s) inside Invoke().

Pavel Radzivilovsky
Calling `GC.Collect()` actually will stop the handles from increasing. Interestingly, if `GC.Collect()` is added after the program has been running a while, during a break point, it will not reduce the handles to an initial state, but rather simply prevent them from accumulating.
JYelton
+2  A: 

The Control.Invoke() method doesn't consume any handles. However, this code is clearly called from a thread. A Thread does consume handles, 5 of them.

The Thread class doesn't have a Dispose() method, although it ought to have one. That was probably by design, it would be very difficult to call reliably, impossibly so for threadpool threads. The 5 handles that a thread requires are released by the finalizer. Your program will require ever increasing amounts of handles if the finalizer never runs.

Not getting the finalizer to run is quite unusual. You would have to have a program that starts a lot of threads but doesn't allocate a lot of memory. This tends to only happen in static tests. You can diagnose this condition with Perfmon.exe, use the .NET memory performance counters and check if gen #0 collections are being done.

If this happens in a production program then you'll have to call GC.Collect() yourself to avoid a runaway handle leak.

Hans Passant
I have used the described pattern to update UI components in the past, without the handle-increase problem, but in the current project it is very certainly something to do with this thread-to-UI call. If I comment out the portion that checks and calls the delegate, and instead `CheckForIllegalCrossThreadCalls = false;` then the handles stop increasing, though I don't want to leave it in such a state. I will update the question with this info.
JYelton
Well, that defies an easy explanation. Give us some idea what the rest of the code does and at what specific statement you see the handle count increase.
Hans Passant
Added a sample that shows the problem in more detail. A button on the form triggers the update.
JYelton
A: 

I actually see the same problem occuring as JYelton. I have the same call from within a thread to update the UI.
As soon as the line 'someControl.Invoke(new DelegateUIUpdate(UIUpdate));' is called, the handle increases by one. There is certainly a leak of some kind on the invoke, but I have no idea what is causing it. This has been verified on several system.

Spencer