Question about aborting a thread.

[Robin Tucker]

Hi there,

I have a "worker thread", which can perform one of many tasks, including
fetching and sending data blobs to a database, load files etc. Now, a
progress dialog is displayed while the thread is performing these actions
with a "cancel" button on it. My question is, at what point does the thread
actually stop running after I have executed "Abort" in response to the user
pressing cancel? Is it immediate? Or does the thread continue processing
until a convienient moment is found to stop it running? In theory, if I
have, say, 100 transactions to perform, I would like the thread to abort on
completion of any single transaction (atomic) - here by transaction I mean,
for example: {loading a file, processing the file, adding it to the
database}. I don't like the idea of having a boolean flag inside the thread
loop (m_bCancelling for example), because the calling thread will not be
able to execute until the current one is cancelled. The caller cannot block
however waiting for it to finish before kicking off the new operation,
because the thread itself uses Invoke on the caller to execute events! (ie.
deadlock). Any ideas? (was I obtuse enough!??)

Thanks

Robin

 

[Jerry Ham]

According to the docs, it aborts at a "safe place" (I'm still not 100% sure
what that means!). however, it will not abort it while it is in native code
(so P/Invoke or anywhere that it calls into native code itself).

I had a very unintended change to my thread aborts when I was doing some
work to get rid of a com interop assembly. I was using GetObject on a type
of IAdsUser (which required the com interop assembly). I moved to using the
DirectorySearcher for more of the work. Previously, my threads would abort
approximately immediately. Now, they wait for their operation to finish (I
guess because the directory searcher isn't a "safe" abort location?).

Jerry