Question

Based on the following question:
General purpose FromEvent method

How do I know which thread in my application the event will return?
I can somehow specify which thread will it continue?
What happens to the thread that is using this feature?

These responses appear to be obvious when I use WPF (Dispatcher/Main/UI Thread), but if I’m working with threads MTA, STA, Reactive, ThreadPool (Task/BackgroundWorker), how can I predict what will happen?

Is there any real benefit than using task.Wait() (if I do not have to worry about locking thread)?

Answer 1

How do I know which thread in my application the event will return?

You don’t. You never do with events, unless the documentation for a specific event specifies the that it will be executed from the UI thread, a thread pool thread, etc.

I can somehow specify which thread will it continue?

If you want to run code in a UI thread then marshal to the UI thread in the event handler. If you want to run code in a thread pool thread then add a new task to the thread pool inside of the handler. Both of those tasks add overhead if not needed, so it’s usually best to look at the documentation of the event to see which is needed.

However, in the case of the linked question, the whole idea is that you’re no longer dealing with an event and an event handler, you’re dealing with a Task. So if you add a continuation to the task, the question is where will that continuation run? That is entirely specified by you. You can use the default task scheduler and have it run in the thread pool, you can pass a UI SynchronizationContext to run in the UI thread, or you can just let it run wherever the task you are continuing runs. (Meaning you have no idea what thread will be running it.)

If you’re using the task with await, then it will automatically configure the continuation to run in the synchronization context you were in before you started that async operation, which may or may not be the UI thread (but likely is). If you specifically don’t want that, then use .ConfigureAwait(false);.

Is there any real benefit than using task.Wait() (if I do not have to worry about locking thread)?

The reason to use an asynchronous task based approach is that you’re not blocking threads, particularly thread pool threads (since you’ve specifically said you’re not blocking a UI, which is much worse). Having a thread sitting around doing nothing is a problem, in some environments more than others (such as ASP for a highly active site). By not doing a blocking wait, you aren’t consuming those resources.