BackgroundWorker

[elziko]

I know I can stop my thread by using the CancelAsync method of the
BackgroundWorker but that requires me to monitor the value of the
CancellationPending property in my BackgroundWorker.DoWork event.

This means that if the DoWork event is processing a single line of code then
my code must wait for this line to finish before it can check the value of
CancellationPending.

What if the user wants to cancel before I can check this value? Is there any
way to outright kill the thread, immediately without monitoring any
properties within DoWork?

TIA

 

[Kevin Spencer]

What are your specific requirements? IOW, what business requirement is this
solution supposed to satisfy?

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

The man who questions opinions is wise.
The man who quarrels with facts is a fool.

 

[Patrice]

AFAIK terminating a thread by using brute force (Abort) is considered as a
bad practice.

Executing few lines of code should be really unoticeable to your user
anyway. If you found an issue with your current approach, I would suggest
posting first about this issue instead of already choosing another
approach...

 

[elziko]

Executing few lines of code should be really unoticeable to your user
anyway.

OK, heres a bit more background on what I'm doing:

I have a requirement to create a netCDF file that contains two records of
data. You're probably not aware of netCDF files but they are commonly used
to store scientific data.

In one line of code in my thread I call a method in a COM DLL that provides
netCDF support that creates a netCDF file capable of storing our data. This
is basically a four dimensional array of size 150 x 150 x150 x 500 as an
example or a record. It is this single line that sometimes takes several
minutes to execute and I'd like the user to be able to cancel during this
time.

Perhaps a few lines of code shouldn't really be noticeable but that depends
on what each line does! Especially when a line of code is just a call to
someone elses code that I have no control over. I don't see how it could be
designed differently. I must use the netCDF format and the COM DLL that I
use to access netCDF files is not something I can change.

I hope that makes things a bit clearer!

TIA

 

[Patrice]

If you abort the thread during this, I'm afraid it could left the whole
stuff in an unpredictable state (or have you checked that this library
doesn't have support for doing this).

Another strategy might be to let the thread continue and to launch another
thread if the user wants to perform some other background task.

Also the likelyness the user will want to abort may vary with the
significance of this operation (i..e it's more likely you'll want to cancel
an everyday computation if you remember your forgot to enter data rather
than a DB creation operation that you lauch every few months really when you
need it).

 

[Kevin Spencer]

I don't think you have much of a choice here. The COM DLL is a black box,
and you don't know what will happen if you abort the thread while it is
running a task. Of course, since it's a background thread, all you really
need to do is have it delete the file afterwards if the user cancels. They
should not experience any change, because it's a background thread. Unless I
misunderstand you.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

The man who questions opinions is wise.
The man who quarrels with facts is a fool.