Question

For the sake of argument, consider a UI thread as a thread that has had a call to Application.Run() or one of it’s overloads called on it and has an active message loop running.

Is there a way of detecting if we’re currently executing on such a thread?

The reason I want this is because I have a class with a private function that is long-running. The class itself is already multithreaded, and the usage of this class is such that it might be used from either the UI or from background threads doing processing. This function also falls into this net. But I don’t want it to block up the UI thread. So I want to detect if I am running on a UI thread and if so, fork the function call into a background thread (probably ThreadPool, but that’s a non-issue for this discussion). This is entirely well-behaved, but the background threads are probably relying on the output of the function, so blocking for them is better, whereas the UI thread is accessing it in a more “set-and-forget” manner.

Answer 1

I would suggest that it’s the kind of decision the caller should make. You could always write wrapper methods to make it easier – but it means that you won’t have problems with the caller being in an “odd” situation (e.g. a UI framework you don’t know about, or something else with an event loop) and you making the wrong decision for them.

If the method ever needs to provide feedback in the right thread, I’d pass in an ISynchronizeInvoke (implemented by Control) to do that in a UI-agnostic way.