Question

Or, equivalently, how would you design such an API. Expected/example usage would be illustrative as well.

My curiosity comes directly from the comments (and subsequent editting on my part) of this answer. Similar questions/discussions in the past provide a bit of inspiration to actually asking it.

Executive summary:
I don’t feel a multithreaded UI api is possible in a meaningful way, nor particularly desirable. This view seems somewhat contentious and being a (relatively) humble man I’d like to see the error of my ways, if they actually are erroneous.

_{*Multithreaded is defined pretty loosely in this context, treat** it however makes sense to you.}

---

Since this is pretty free-form, I’ll be accepting whichever answer has the most coherent and well supported answer in my opinion; regardless of whether I agree with it.

Answer Accepted

---

**Ok, perhaps more clarification is necessary.

Pretty much every serious application has more than one thread. At the very least, they’ll spin up an additional thread to do some background task in response to a UI event.

I do not consider this a multithreaded UI.

All the UI work is being done on single thread still. I’d say, at a basic level, a multithreaded UI api would have to do away with (in some way) thread based ownership of UI objects or dispatching events to a single thread.

Remeber, this is about the UI api itself; not the applications that makes use of it.

Answer 1

I don’t see how a multithreaded UI API would differ much from existing ones. The major differences would be:

• (If using a non-GC’d language like C++) Object lifetimes are tracked by reference-counted pointer wrappers such as std::tr1::shared_ptr. This ensures you don’t race with a thread trying to delete an object.
• All methods are reentrant, thread-safe, and guaranteed not to block on event callbacks (therefore, event callbacks shall not be invoked while holding locks)
• A total order on locks would need to be specified; for example, the implementation of a method on a control would only be allowed to invoke methods on child controls, except by scheduling an asynchronous callback to run later or on another thread.

With those two changes, you can apply this to almost any GUI framework you like. There’s not really a need for massive changes; however, the additional locking overhead will slow it down, and the restrictions on lock ordering will make designing custom controls somewhat more complex.

Since this usually is a lot more trouble than it’s worth, most GUI frameworks strike a middle ground; UI objects can generally only be manipulated from the UI thread (some systems, such as win32, allow there to be multiple UI threads with seperate UI objects), and to communicate between threads there is a threadsafe method to schedule a callback to be invoked on the UI thread.