Cancel BackgroundWorke r

[=?Utf-8?B?anAybXNmdA==?=]

How do you cancel a BackgroundWorke r?

For this BackgroundWorke r:

bgWorker.Worker ReportsProgress = true;
bgWorker.Worker SupportsCancell ation = true;

I have tried this, but it never exits the do...while loop:

if (bgWorker.IsBus y == true) {
bgWorker.Cancel Async();
}
do {
Thread.Sleep(0) ;
} while (bgWorker.IsBus y == true);

I tried removing the do...while loop, but then I get errors because the
thread is still being used!

[Peter Duniho]

On Thu, 11 Sep 2008 11:24:00 -0700, jp2msft
<jp*****@discus sions.microsoft .comwrote:

How do you cancel a BackgroundWorke r?

See the MSDN documentation for the class. It includes an example of a
cancelable BackgroundWorke r.

The short story: your DoWork handler needs to take into account the
possibility of cancellation, checking for that condition at opportune
moments during processing and terminating early when canceled.

From the docs for BackgroundWorke r.CancelAsync() :

The worker code should periodically check the
CancellationPen ding property to see if it has
been set to true.

Pete

[=?Utf-8?B?anAybXNmdA==?=]

I copied their example, and I even have my thread checking to see if it has
been cancelled within its loops:

if (worker.Cancell ationPending == true) {
e.Cancel = true;
return;
}

This part of the code is triggered, but when this happens, the code does not
enter the bgWorker_Progre ssChanged or bgWorker_RunWor kerCompleted event
handlers.

Because of this, my do...while loop never exits.

How is this fixed?

BTW: Thanks for your help, too!

"Peter Duniho" wrote:

See the MSDN documentation for the class. It includes an example of a
cancelable BackgroundWorke r.

The short story: your DoWork handler needs to take into account the
possibility of cancellation, checking for that condition at opportune
moments during processing and terminating early when canceled.

From the docs for BackgroundWorke r.CancelAsync() :

The worker code should periodically check the
CancellationPen ding property to see if it has
been set to true.

Pete

[Peter Duniho]

On Thu, 11 Sep 2008 13:17:01 -0700, jp2msft
<jp*****@discus sions.microsoft .comwrote:

I copied their example, and I even have my thread checking to see if it
has
been cancelled within its loops:

if (worker.Cancell ationPending == true) {
e.Cancel = true;
return;
}

This part of the code is triggered, but when this happens, the code does
not
enter the bgWorker_Progre ssChanged or bgWorker_RunWor kerCompleted event
handlers.

Because of this, my do...while loop never exits. [...]

Unless you post a concise-but-complete code sample that demonsrates
exactly what you're doing, it's not possible to say what you're doing
wrong. The RunWorkerComple ted event definitely should be raised, but
there's nothing in the code you post that proves that you're handling it,
never mind that it would affect the loop you posted.

The most likely explanation is that the loop you posted is executing on
the main GUI thread, and of course doing so would cause all sorts of
issues, including this one. But without all the code, it's impossible to
say for sure what's going on.

That said, I'll point out that just from the little code you've posted,
it's clear that your basic strategy is simply wrong. There is no sense in
handing off work to a different thread only to have the current thread sit
and wait for it to be done. There also is _especially_ no sense in
writing a "busy wait" as you've done here, where the only thing the loop
does is repeatedly check for a specific condition. Even in situations
where it makes sense for a thread to wait for something to happen (and
this doesn't appear to be such a situation), there are correct ways to
wait, such as using a WaitHandle sub-class, that don't consume CPU
resources uselessly as your code does.

If you can provide a concise-but-complete code sample, I'm sure I or
someone else can provide more useful advice. Until then, I remain
unoptimistic. :)

Pete

[=?Utf-8?B?anAybXNmdA==?=]

I wished I could provide an attachment, but I can't.

I added one ugly Application.DoE vents() to the wait loop, and my thread went
into the RunWorkerComple ted section.

I could email you the file, if you are interested. You can send your email
address to me at jpool at aaon dot com.

[Peter Duniho]

On Thu, 11 Sep 2008 14:17:03 -0700, jp2msft
<jp*****@discus sions.microsoft .comwrote:

I wished I could provide an attachment, but I can't.

Sure you can. If you want the best answer, you must.

It doesn't have to be the full code you're working with. In fact, it
typically shouldn't be. But it does have to be complete, and it does have
to reproduce the problem.

Every question ever posted to this newsgroup has such as
"concise-but-complete" code sample that goes along with the question.
Often the person posting the question fails to include the sample, but one
always exists.

I added one ugly Application.DoE vents() to the wait loop, and my thread
went
into the RunWorkerComple ted section.

Don't do that. Calling DoEvents() is simply bad generally (the biggest
issue is that it introduces re-entrancy to code that has almost certainly
not been designed with re-entrancy in mind), and in this case it only
emphasizes how defective your current design is (you should never be
blocking the GUI thread, and I'll reiterate that having one thread just
sit and wait for another thread is always the wrong thing to do).

I could email you the file, if you are interested. You can send your
email
address to me at jpool at aaon dot com.

Any code sample I'd be willing to read through would be appropriate to be
posted here.

That said, based on your reply, it sounds like you've confirmed my guess
as to what's wrong. The correct resolution is to fix your design so that
the main GUI thread isn't waiting on the worker thread at all. Put all of
the logic that occurs after the wait into a method that can be called by
the RunWorkerComple ted event handler, or into that handler's method
itself. The main GUI thread should simply start the worker and then
return.

Pete

[=?Utf-8?B?anAybXNmdA==?=]

Ok, here is a small test section that I have put together to illustrate my
problem:

We have an SQL query that takes 60-120 seconds to run for each employee (the
SqlCommand's CommandTimeout is set to 120 seconds and this seems to give the
queries enough time).

public static string m_fmtSql = "SELECT LOTS OF STUFF WHERE EMPLOYEE='{0}'" ;
public static SqlConnection m_conn; // set elsewhere

void worker_DoWork(o bject sender, DoWorkEventArgs e) {
List<stringEmpl oyees = (List<string>)e .Argument;
List<stringErro rs = new List<string>();
List<stringResu lts = new List<string>();
BackgroundWorke r worker = sender as BackgroundWorke r;
int Count = 0;
foreach (string person in Employees) {
if (worker.Cancell ationPending == true) {
e.Cancel = true;
return;
}
Count++;
worker.ReportPr ogress(100 * Count / Employees.Count );
DataTable dt = new DataTable();
string sql = string.Format(m _fmtSql, person);
using (SqlDataAdapter da = new SqlDataAdapter( sql, m_conn)) {
try {
da.Fill(dt); // this step takes 60-120 seconds to run
} catch (SqlException err) {
Errors.Add(err. Message);
}
}
if (0 < dt.Rows.Count) {
string fmt = "{0};{1};{2};{3 };{4};{5};{6}";
string var1, var2, var3, var4, var5;
int var6, var7;
// work with data, manipulate some figures, then add it to the results
string result
= string.Format(f mt, var1, var2, var3, var4, var5, var6, var7);
Results.Add(res ult);
}
}
e.Result = Results;
}

void worker_RunWorke rCompleted(obje ct sender, RunWorkerComple tedEventArgs e) {
if (e.Error != null) {
// display error
} else if (e.Cancelled == true) {
// display that status
} else if (e.Result is List<string>) {
List<stringResu lts = (List<string>)e .Result;
DataGridView1.R ows.Clear();
foreach (string line in Results) {
string[] data = line.Split(new char[] { ';' });
DataGridView1.R ows.Add(data);
}
}
}

void BtnCancel_Click (object sender, EventArgs e) {
if ((WorkerThread. IsBusy == true) &&
(WorkerThread.S upportsCancella tion == true)) {
WorkerThread.Ca ncelAsync();
// Here is the point of concern:
// since the SQL call could take up to 2 full minutes to complete,
// our Users are liable to try running the report again while
// the thread is still active.
// So, the solution is to disable the "Run Report" button until
// this thread has finished:
BtnRunReport.En abled = false;
do {
Thread.Sleep(0) ;
} while (WorkerThread.I sBusy == true);
BtnRunReport.En abled = true;
// The problem is:
// This code is so busy in the loop, that the
// "RunWorkerCompl eted" code does not have a chance to run.
// If I write in the ugly "Application.Do Events();" within the
do...while loop,
// the application will stop itself, but that is a bad fix.
}
}

[Peter Duniho]

On Fri, 12 Sep 2008 09:14:07 -0700, jp2msft
<jp*****@discus sions.microsoft .comwrote:

Ok, here is a small test section that I have put together to illustrate
my
problem:

Please see http://www.yoda.arachsys.com/csharp/complete.html

Based on what you've written so far in this thread, I believe my previous
comments should be sufficient in helping you fix your code. But if you
feel there's a need for further elaboration, you need to post a true
concise-but-complete code sample. What you just posted is neither.