完全同意，我们希望一切都是具有清晰结构的通用通信类型。
借用一个陈词滥调 - 你可以以任何方式与其他组件进行通信...只要它是总线消息😛

在某个时刻，我知道我们已经废弃了整个信号系统，并计划将其完全移除。
然而，像信号管理器这样的东西会很酷，用于跟踪状态。那时候，我想象了一个类似于threading.Event的东西，但由消息总线支持，以实现跨模块。棘手的部分是在启动时进行同步，以确保新进程知道当前状态，如果它被重启或启动得晚了等等。我甚至为此编写了一个提案，但当时团队对此并不感兴趣。这个信号管理器似乎与此类似，对吗？还有更多吗？

信号管理器是存在于消息总线客户端模块中的东西吗？因为我们在那里做的一件事就是设置通过消息总线进行通信的标准方式以及辅助原语？

信号管理器是存在于消息总线客户端模块中的东西吗？因为我们在那里做的一件事就是设置通过消息总线与辅助原语进行标准通信的方式？
我将信号管理器与消息总线服务放在一起；这似乎是在每个"核心"中强制使用一个示例的最佳位置，因为(1)如果已经有一个活动的总线，服务将无法启动，(2)我认为消息总线定义了一个离散的"核心"。
棘手的部分是在启动时进行同步，以确保新进程知道当前状态，如果它被重启或启动得晚了等等。
我只是使用Messages来设置和查询信号，所以进程是无状态的，SignalManager对象是事实的来源。
借用一个说法-你可以用任何你喜欢的方式与其他组件进行通信...只要它是总线消息😛
这是我在查看如何与模块通信时的座右铭。我在这里受到的启发是，我将Neon添加的所有信号都重构为总线消息，并认为这对于一般信号来说只是一个更好的实现方式

明白了，听起来比我提出的方案简单 :)
但是也许信号类可能在那里是一个很好的匹配，如果信号管理器是消息总线服务的一个功能，与它的交互应该在客户端模块中？或者这让它离它的父级太远了吗？

明白了，听起来比我提出的方案简单 :)
但是也许信号类可能在那里是一个很好的选择，如果信号管理器是消息总线服务的一个功能，那么它应该在客户端模块中吗？或者这让它离它的父级太远了吗？
嗯，我之前没有想过在管理器之外使用 Signal 类；我专注于与 create_signal 和 check_for_signal 方法的向后兼容性。我认为除非有检查最后创建时间的使用场景，否则没有必要直接与 Signal s 交互。即使如此，也可以通过总线事件来处理。
我创建 Signal 类的唯一原因是有一个 created 事件和一个 cleared event,所以等待(创建或清除)的两种情况都可以使用事件触发器而不是轮询。