Jeremy CHEN

编译器选qcc和q++试试

1. 编译ARM版本用aarch64-unknown-nto-qnx7.0.0-gcc/g++ 2. 取master最新版本，c++规范改成了gnu++11 这样是可以编译通过的

首先看一下使用的是不是最新版本。其次解释一下性能测试过程：首先在一端把fdbxserver启动起来，然后在另一端把fdbxclient启动起来，后者会发送大量数据给前者，前者再把收到的数据复制一份reply给后者。 fdbxclient是以burst位单位来发送，每个burst包含若干个block的连续数据。为了测试出准确的性能，在启动fdbxclient时需要把参数调整好，以期达到最佳效果，这些参数包括： -d delay：两个burst之间插入的时间间隔大小，以微秒为单位；默认是0 -s burst size: 一个burst包含的block个数，默认是16 -b block size: 每个block包含的字节数，默认是1024 当以默认参数运行时，发送的数据量是很大的，会造成阻塞。是否发生阻塞可以看打印出来的“Pending Req”列，如果不断在增大说明阻塞严重，需要用-d插入延时，直到稳定为0或1为止。为了调整测试压力可以调整-b和-s：加大-b可以增加一次连续传输的数量，减少消息交互上的开销；加大--s可以在两个延时之间插入更多block。 调整以上参数使得Data Rate达到最大值，同时“Pending Req”维持很小，Failure为0。注意Data Rate是单向的带宽。实际通信是双向的，双向带宽要x2。 另外一个性能指标是延时。测延时时要把-d放得比较大，-s放小，确保“Pending Req”一直为0。这时候由于没有消息堆积，测出的delay就是线路上花费的时间，也就是从client到server，再从server返回这样一个来回花费的时间。

从版本c3346545开始，把socket的send和recv标志位MSG_DONTWAIT去掉了，从而确保消息可靠收发。这样做的代价是socket收发可能会block，一个socket出问题会造成进程里所有的client/server都不能正常工作。

This is really a problem. For QNX, sem_timedwait_monotonic() solve the problem, but it is a BB OS extension. For Linux, there is no replacement. One workaround is to create worker...

Sorry already fixed: for QNX -Dfdbus_QNX_KEEPALIVE=ON should be added to QNX.

At this moment, since all data structures are handled in context thread, there is no need to protect them with mutex lock. On the other hand, there is not need...

你用的是哪个版本？目前看这个问题发生在master最近的版本上，今天的提交顺便解决了。v4.2.0-release分支上应该没有这个问题。

谢谢你花这么多时间报告这些问题。python版本确实没有仔细验证过，但既然提供了就要做好。接下来会把python好好整理一下，按照你提的几点来验证。 Update 2021/01/12: 问题已经解决了，python版本可以正常工作。

我在main_xclient.cpp里增加了-y选项用于测试同步调用： 1. 启动服务：fdbxserver 2. 启动客户：fdbxclient -y -d 100000 -s 1 最后一列记录的是最大延时。我测试下来没有出现2.5秒的情况，你可以用这个方法测一下，有什么问题再反馈，谢谢！