RTT为什么没有用IPC里的队列实现字符流接收呢？

用队列存字节流？一个字节占12个字节？一个链表结点携带一个字节有效数据？

妥了妥了，顺便问一下用信号量的话，里面经常出现rt_sem_control(client->resp_notice, RT_IPC_CMD_RESET, RT_NULL); 在其他RTOS里面移植可不可以直接去掉还是改成零等待的eat一下信号量呢？

比较危险的操作，能不用就不用的好

使用IPC中的队列和使用信号量加FIFO在实现上有一些不同之处。
首先，IPC中的队列是由操作系统内核提供的一种机制，而信号量加FIFO则需要应用程序自己实现。因此，在某些情况下，使用IPC中的队列比使用信号量加FIFO更容易实现，并且更加可靠。
其次，IPC中的队列通常具有更强的容错性。当一个进程向队列发送消息时，即使目标进程当前没有等待接收消息，消息也会被存储在队列中，直到目标进程准备好接收为止。而在信号量加FIFO中，如果没有等待的进程，消息就会被直接丢弃。
此外，IPC中的队列还可以支持多个读取者和写入者，而信号量加FIFO通常只能支持单个读取者和写入者。
最后，两者的应用场景也略有不同。IPC中的队列通常用于进程间通信，特别是在多处理器或多核处理器系统中。而信号量加FIFO通常用于单进程中不同任务之间的通信。
综上所述，使用IPC中的队列和使用信号量加FIFO在某些情况下可以交替使用，但在不同的应用场景中可能有不同的优缺点。具体选择哪种方式要根据实际需求进行权衡。