2012-03-08 3 views
0

Я бегу процесс в отдельном потоке, чтобы облегчить параллелизм и плавный пользовательский интерфейс вызоваРабота с TPL Использование встроенных задач

private void ThreadedTestConnection(SqlConnection conn, bool bShowErrMsg) 
{ 
    Task<bool> asyncTestConn = Task.Factory.StartNew<bool> 
     (() => TestConnection(conn, bShowErrMsg)); 
    return asyncTestConn.Result; 
    asyncTestConn.Dispose(); 
} 

из потока пользовательского интерфейса. Однако «ожидание», вызванное return asyncTestConn, останавливает поток пользовательского интерфейса, возвращаемый обратно в графический интерфейс. Я придумал следующее исправление. От события уволен из графического интерфейса у меня есть (не включая try/catch блоков)

private void SomeClick_Event(object sender, EventArgs e) 
{ 
    Task testConnection = Task.Factory.StartNew 
     (() => UtilsDB.ThreadedTestConnection(mainConn, true)); 
} 

Это работает. То есть, он сразу же возвращает управление GUI во время выполнения теста на отдельном фоновом потоке. Могу ли я быть глупым мальчиком в этом, или это хорошо?

Примечание: Это отдельный вопрос, связанный с this one. Я не получил удовлетворительного ответа.

ответ

1

Это прекрасно, вы только начинаете задачу «стрелять и забывать», которая будет запускаться в потоке потока потока, однако в первом примере вы, кажется, ожидаете результата (я предполагаю, что логическое значение указывает, связано ли соединение тест был успешным) - во втором случае у вас их не будет - если ваша задача, например, вызывает событие или вызывает предопределенный обратный вызов.

+0

Большое спасибо за ваше время. Должен ли я распоряжаться «Задачей», или это будет «сбор мусора» в самом слабом смысле этого слова? – MoonKnight

+1

, если вы не используете дескрипторы событий, вам не нужно будет распоряжаться «Задачей» - см. Также http://stackoverflow.com/questions/3734280/is-it-considered-acceptable-to-not-call-dispose-on -a-TPL-задача-объект – BrokenGlass

Смежные вопросы