您的功能请求是否与问题相关？请描述。
当前信号文件的实现依赖于查询文件系统以确定特定文件的存在。这意味着使用循环检查，消耗处理周期且不考虑已删除并重新创建的文件(例如 isSpeaking )。这也意味着信号检查必须来自具有共享文件系统的模块，这对容器来说是具有挑战性的。
描述您希望的解决方案
我实现了一个 SignalManager in Neon ,它使用总线事件来设置/清除/等待信号。默认情况下，信号文件仍然写入磁盘以保持向后兼容性，但检查或等待信号的方法使用事件而不是重复的文件系统检查。
描述您考虑过的替代方案
大多数信号使用可以完全移除，但 isSpeaking 尤其难以重构。此外，使用信号的技能仍应得到支持。
附加上下文
此的主要动机是在容器中运行模块，如 in Neon 所实现的那样。
6条答案
按热度按时间pb3s4cty1#
完全同意，我们希望一切都是具有清晰结构的通用通信类型。
借用一个陈词滥调 - 你可以以任何方式与其他组件进行通信...只要它是总线消息😛
flseospp2#
在某个时刻，我知道我们已经废弃了整个信号系统，并计划将其完全移除。
然而，像信号管理器这样的东西会很酷，用于跟踪状态。那时候，我想象了一个类似于
threading.Event的东西，但由消息总线支持，以实现跨模块。棘手的部分是在启动时进行同步，以确保新进程知道当前状态，如果它被重启或启动得晚了等等。我甚至为此编写了一个提案，但当时团队对此并不感兴趣。这个信号管理器似乎与此类似，对吗？还有更多吗？zmeyuzjn3#
信号管理器是存在于消息总线客户端模块中的东西吗？因为我们在那里做的一件事就是设置通过消息总线进行通信的标准方式以及辅助原语？
5lwkijsr4#
信号管理器是存在于消息总线客户端模块中的东西吗？因为我们在那里做的一件事就是设置通过消息总线与辅助原语进行标准通信的方式？
我将信号管理器与消息总线服务放在一起；这似乎是在每个"核心"中强制使用一个示例的最佳位置，因为(1)如果已经有一个活动的总线，服务将无法启动，(2)我认为消息总线定义了一个离散的"核心"。
棘手的部分是在启动时进行同步，以确保新进程知道当前状态，如果它被重启或启动得晚了等等。
我只是使用Messages来设置和查询信号，所以进程是无状态的，
SignalManager对象是事实的来源。借用一个说法-你可以用任何你喜欢的方式与其他组件进行通信...只要它是总线消息😛
这是我在查看如何与模块通信时的座右铭。我在这里受到的启发是，我将Neon添加的所有信号都重构为总线消息，并认为这对于一般信号来说只是一个更好的实现方式
mnemlml85#
明白了，听起来比我提出的方案简单 :)
但是也许信号类可能在那里是一个很好的匹配，如果信号管理器是消息总线服务的一个功能，与它的交互应该在客户端模块中？或者这让它离它的父级太远了吗？
t9eec4r06#
明白了，听起来比我提出的方案简单 :)
但是也许信号类可能在那里是一个很好的选择，如果信号管理器是消息总线服务的一个功能，那么它应该在客户端模块中吗？或者这让它离它的父级太远了吗？
嗯，我之前没有想过在管理器之外使用
Signal类；我专注于与create_signal和check_for_signal方法的向后兼容性。我认为除非有检查最后创建时间的使用场景，否则没有必要直接与Signals 交互。即使如此，也可以通过总线事件来处理。我创建
Signal类的唯一原因是有一个created事件和一个cleared event,所以等待(创建或清除)的两种情况都可以使用事件触发器而不是轮询。