The lifetime of the thread is not affected by the "desire" of other threads
to deliver events, notifications, or callbacks to it. If you kill the
thread, and it leaves its threadfunc, then it is gone. There is a
distinction to be made here between the thread, and a class object instance
that may be associated with the thread - the thread can be gone while the
object instance is still valid.
The actual behavior will really vary based upon what asynchronous method you
called. You can write your own asynchronous objects and make it handle the
callback in any manner you desire. If you have invoked a runtime routine
then you will get whatever behavior they specify.
In general the rule is that once you initiate an asynchronous call unless
there is a mechanism for aborting or canceling the transaction then the
callback will be called regardless of what the original invoking thread has
done. There is also a distinction to be made between a worker thread
terminating/aborting versus the object instance used as the context in the
call. The worker thread may terminate while the object that was associated
with it may still be valid.
It may also be the case that the callback is delivered on an arbitrary
thread (e.g. one of the threads in the ThreadPool), in which case it is the
object instance (the context) that is important, not the thread itself that
it is delivered on. In fact, I would expect this to be how it was delivered
if the async call was initiated from a worker thread, as there is no UI
mechanism it could use to deliver the callback on a specific thread.
Regardless, it is up to you the developer to ensure that required thread
safety issues are dealt with.
It would help if you could specify the type of worker thread (does it have a
UI or not, background or foreground), and the actual async call you are
planning on using.
