[参考译文] RTOS/AM5726：MessageQ 远程收件人脱机

RTOS 团队已收到通知。 他们将在这里作出回应。

Tim、

如果您在 MessageQ API 中指定'timeout'值而不是'imageQ_fore'、它是否有助于检测远程端故障？

int MessageQ_get (MessageQ_Handle handle、
MessageQ_Msg *msg，
通用 超时)

此致、
Garrett

Garrett、

我们现在就这样做、这不是足够的权变措施。
我们有一条保持活动消息、即 Linux 应用每 n ms 发送一次-遗憾的是、n 不是常量、最多可以增加一秒(这就是 DSP 处理实时部分的原因)。 在 DSP 端、MessageQ_get 以大约2秒的超时进行调用、如果呼叫返回时指示超时、我们将"关闭"远程连接(意味着：我们删除有关远程队列的所有信息-不再发送消息)。 但这太晚了、当远程队列关闭时、MessageQ_get 似乎不会返回。 怎么可能呢？ 这是一个 n：1连接、在本地队列上调用"Get"、而不是在远程队列上调用。

从理论角度来看、我假设只有 MessageQ_Put 调用能够充分检测到已关闭的远程队列、因为即使有一种方法可以"询问"系统是否仍处于打开状态、 "询问"和 MessageQ_Put 调用必须是原子调用才能确保安全。

最棒的

Tim

您好、Garrett、

此主题有什么新内容？ 我仍然卡在。

最棒的

Tim

Tim、

>>当远程队列关闭时、MessageQ_get 似乎不会返回。
您是否意味着当远程队列关闭时超时不会生效？ 还是超时延迟太高？ 检测主机断开的时间要求是多少？

此致、
Garrett

MessageQ_get 在超时后会愉快地返回、但不会返回超时以外的错误。 特别是它不反映远程队列的状态。 请再次阅读我在2017年10月6日凌晨3：36的消息、我想我已经清楚地说明了为何 IMHO 无法通过调用 MessageQ_get 来解决该问题。

Tim、

如果您每 n ms 发送一次 keepalive 消息、那么 MessageQ_get 由于超时而返回应该表示远程队列失败。 MessageQ_Put 可能不起作用、因为 MessageQ_Get 和 MessageQ_Put 都通过相同的 rpmsg 传输。 尽管 MessageQ_get 从本地队列接收消息、但它的消息实际上是 MessageQ_Put 从远程端接收的。 如果您的应用程序需要一个硬实时时间来通知远程收件人脱机、您可能需要开发一个基于邮箱的自定义握手机制、请参阅此处的讨论： e2e.ti.com/.../604259

此致、

Garrett

Garrett、

 感谢链接、我认为我必须重新思考我的 RTOS 任务模型。 应该可以始终在与接收相同的任务中执行发送-这是使 MessageQ_get 超时停止与 ARM 端的通信所必需的先决条件。

除此之外、我想知道什么会使 RPMSG 层从 MessageQ_Put 调用返回如此长的时间？ 是否可以通过任何类型的配置来控制此时间跨度？

最棒的

     Tim