TPL How to Perform a 'Call-Back'

Question

I have a small application that needs to test SQL connection strings for a number of connections (each done one-at-a-time). To do this I set the ConnectionTimeout = 5 temporarily to avoid a long wait if the connection is not valid and ConnectionTimeout = 0 (wait forever), say.

To avoid the UI hanging whilst we attempt to Open() a bad connection (even with ConnectionTimeout = 5 the wait for the SqlException can be up to twenty seconds), I want to run the test on a separate thread using Task Parallel Library (TPL). So I spin-off my new thread like:

Task<bool> asyncTestConn = Task.Factory.StartNew<bool>
    (() => TestConnection(conn, bShowErrMsg));
return asyncTestConn.Result;

The problem is that this is still locking the UI (clearly), as it is waiting for the result before returning to the caller. How do I allow the code to return control to the UI (freeing up the GUI) whilst getting the eventual result from the asynchronous Task?

Also, from within a Task can I legitimately do MessageBox.Show("Some message")? This does not work for BackgroundWorkers and this pooled-thread is a background thread by default; yet it does not seem to be a problem. Thanks for your time.

score 5 · Answer 1 · answered Mar 08 '12 at 14:26

For the TPL, ContinueWith is exactly what you want. Expanding on Henk's answer:

var asyncTestConn = Task.Factory.StartNew(() => TestConnection(conn, bShowErrMsg));
// Henk's "MyFinishCode" takes a parameter representing the completed
// or faulted connection-testing task.
// Anything that depended on your "return asyncTestConn.Result;" statement
// needs to move into the callback method.
asyncTestConn.ContinueWith(task =>
    {
        switch (task.Status)
        {
            // Handle any exceptions to prevent UnobservedTaskException.
            case TaskStatus.Faulted: /* Error-handling logic */ break;
            case TaskStatus.RanToCompletion: /* Use task.Result here */ break;
        }
    },
    // Using this TaskScheduler schedules the callback to run on the UI thread.
    TaskScheduler.FromCurrentSynchronizationContext());

Really helpful. Thanks. The combination of the two answers is absolutely mint. — MoonKnight, Mar 08 '12 at 14:45

H H · Accepted Answer · 2012-03-08T13:07:51.990

4

You are right, this is where the waiting happens:

 return asyncTestConn.Result;

You could simply build the finish-up code in the tail of TestConnection() or use a Continuation:

// untested
//Task<bool> asyncTestConn = Task.Factory.Create<bool> (
Task<bool> asyncTestConn = new Task<bool> (
    () => TestConnection(conn, bShowErrMsg));
asyncTestConn.ContinueWith(MyFinishCode);
asyncTestConn.Start()

can I legitimately do MessageBox.Show("Some message")?

Actually Yes, the MessageBox is thread-safe. Should be possible from a Bgw as well.

But you are prolonging the life of the Task by a lot, it's not a good idea.

edited Mar 08 '12 at 13:07

answered Mar 08 '12 at 12:19

H H

263,252
30
330
514

Thanks very much for your response. The whole idea is to get back to pass control back to the UI/GUI as soon as possible, how does/can the above achieve that? If I am calling the above code from a method called `ParrTestConn(SqlConnection conn, string bShowErrMsg)` then I can't say `asyncTestConn.ContinueWith(ParrTestConn(conn, bShowErrMsg))`... Or can I? – MoonKnight Mar 08 '12 at 12:31
@Killer You can simply return after the Start(). The GUI should stay responsive when using this. – H H Mar 08 '12 at 12:55
I do not have the `Task.Factory.Create` method avilible? – MoonKnight Mar 08 '12 at 13:02

TPL How to Perform a 'Call-Back'

2 Answers2

Linked