api - 多线程 UI api 会是什么样子，它会提供什么优势？

Question

或者，同等地，您将如何设计这样的 API。预期/示例用法也具有说明性。

我的好奇心直接来自于这个 answer 的评论(以及我随后的编辑) 。类似questions/discussions过去为实际提出问题提供了一些灵感。

执行摘要:
我认为多线程 UI API 不可能以有意义的方式实现，也不是特别理想。这种观点似乎有些争议，作为一个(相对)谦虚的人，我希望看到我的方式是错误的，如果它们实际上是错误的。

_{*多线程在这种情况下的定义相当宽松，但对待**它对您来说是有意义的。}

---

由于这是相当自由的形式，我将接受我认为最连贯且得到充分支持的答案；不管我是否同意。

答案已接受

---

**好吧，也许需要更多说明。

几乎每个严肃的应用程序都有多个线程。至少，他们会启动一个额外的线程来执行一些后台任务，响应 UI 事件。

我不认为这是多线程 UI。

所有 UI 工作仍然在单线程上完成。我想说，在基本层面上，多线程 UI api 必须(以某种方式)取消基于线程的 UI 对象所有权或将事件分派(dispatch)到单个线程。

记住，这是关于 UI api 本身的；不是使用它的应用程序。

Answer 1

我不明白多线程 UI API 与现有 API 有什么不同。主要区别是:

• (如果使用非 GC 语言，如 C++)对象生命周期由引用计数指针包装器(例如 std::tr1::shared_ptr)跟踪。这可以确保您不会与尝试删除对象的线程竞争。
• 所有方法都是可重入的、线程安全的，并且保证不会阻塞事件回调(因此，在持有锁时不得调用事件回调)
• 需要指定锁的总订单；例如，控件上方法的实现只允许调用子控件上的方法，除非安排异步回调稍后运行或在另一个线程上运行。

通过这两项更改，您可以将其应用到几乎任何您喜欢的 GUI 框架。实际上并不需要进行大规模的改变；但是，额外的锁定开销会减慢速度，并且对锁定顺序的限制将使设计自定义控件变得更加复杂。

由于这通常带来的麻烦远大于其值(value)，因此大多数 GUI 框架都采取了中间立场； UI 对象通常只能从 UI 线程进行操作(某些系统，例如 win32，允许存在具有单独 UI 对象的多个 UI 线程)，并且为了在线程之间进行通信，有一个线程安全方法来调度要调用的回调UI 线程。