打开 pentacular 开启了这个issue 2021 年 10 月 19 日 · 2 条评论 打开 饱和输入造成的数据丢失#983 pentacular 开启了这个issue 2021 年 10 月 19 日 · 2 条评论 注释 五角星 评论了 2021 年 10 月 19 日 • 编辑 请只提交最新的主要或开发分支的错误。您可以检查启动消息中的版本号并将其与grbl.h中的版本进行比较 请回答以下问题。 您使用的是什么版本的固件? 版本 1.3a 构建 20210424 问题是否可重复? 是的 什么情况下会出现bug? 每当 i/o 输入速率超过 SERIAL 以外的客户端上的消耗速率时。 这个问题似乎是由于 Serial.cpp 中的 clientCheckTask 是如何运作的 while ((client = getClientChar(&data)) != CLIENT_ALL) { if (is_realtime_command(data)) { execute_realtime_command(static_cast<Cmd>(data), client); } else { // ... client_buffer[client].write(data); // ... } } // if something available 该循环不断获取客户端数据,然后尝试写入每个客户端的 InputBuffer,而不考虑可用容量。 当有可用输入但没有输出容量时,这会导致数据丢失。 这种设计的原因似乎是允许提取实时命令。 如果我们看一下 getClientChar static uint8_t getClientChar(uint8_t* data) { int res; #ifdef REVERT_TO_ARDUINO_SERIAL if (client_buffer[CLIENT_SERIAL].availableforwrite() && (res = Serial.read()) != -1) { #else if (client_buffer[CLIENT_SERIAL].availableforwrite() && (res = Uart0.read()) != -1) { #endif *data = res; return CLIENT_SERIAL; } // ... } 我们可以看到CLIENT_SERIAL有特殊处理,除非有相应的输出能力,否则拒绝读取。 将相同的条件添加到其他客户端读取实际上避免了数据丢失问题。 在我看来,这通常是正确的做法。 结果将是饱和的输入将无法传播实时命令(对于今天的 CLIENT_SERIAL),但非饱和的输入将能够并行传播实时命令。 鉴于今天任何饱和输入都会导致灾难性的数据丢失,饱和输入不可能是预期的操作条件。 这意味着添加输出容量检查不应影响当前的工作流程。 期望使用饱和输入(如通过套接字上传文件)的人需要记住实时命令会延迟,并且应该添加对带外信号输入的支持或使用备用客户端实时命令(例如 WEBUI)。 我已经实施并测试了此修复程序,并且可以提供 PR。 请让我知道你在想什么。 五角星 添加了 漏洞 有些东西不工作标签 2021 年 10 月 19 日 合作者 米奇布拉德利 评论了 2021 年 10 月 20 日 请提供PR 合作者 米奇布拉德利 评论了 2021 年 10 月 20 日 PR 对 FluidNC 而不是 Grbl_Esp32 更有用,因为我们的绝大多数开发工作已经转移到 FluidNC。https://github.com/bdring/FluidNC 五角星 提到了这个问题 2021 年 10 月 20 日 在读取串行 i/o 之前检查输出容量,并通过降低交互性对客户端进行排序。 #984 打开 免费注册 在 GitHub 上加入此对话。已有帐户? 登录评论 受让人 无人分配 标签 漏洞有些东西不工作 项目 还没有 里程碑 没有里程碑 发展 没有分支机构或拉取请求 2名参加者
请只提交最新的主要或开发分支的错误。您可以检查启动消息中的版本号并将其与grbl.h中的版本进行比较
请回答以下问题。
您使用的是什么版本的固件?
版本 1.3a
构建 20210424
问题是否可重复?
是的
什么情况下会出现bug?
每当 i/o 输入速率超过 SERIAL 以外的客户端上的消耗速率时。
这个问题似乎是由于 Serial.cpp 中的 clientCheckTask 是如何运作的
该循环不断获取客户端数据,然后尝试写入每个客户端的 InputBuffer,而不考虑可用容量。
当有可用输入但没有输出容量时,这会导致数据丢失。
这种设计的原因似乎是允许提取实时命令。
如果我们看一下 getClientChar
我们可以看到CLIENT_SERIAL有特殊处理,除非有相应的输出能力,否则拒绝读取。
将相同的条件添加到其他客户端读取实际上避免了数据丢失问题。
在我看来,这通常是正确的做法。
结果将是饱和的输入将无法传播实时命令(对于今天的 CLIENT_SERIAL),但非饱和的输入将能够并行传播实时命令。
鉴于今天任何饱和输入都会导致灾难性的数据丢失,饱和输入不可能是预期的操作条件。
这意味着添加输出容量检查不应影响当前的工作流程。
期望使用饱和输入(如通过套接字上传文件)的人需要记住实时命令会延迟,并且应该添加对带外信号输入的支持或使用备用客户端实时命令(例如 WEBUI)。
我已经实施并测试了此修复程序,并且可以提供 PR。
请让我知道你在想什么。