I was just wondering if someone had come across this lately; as I have been trying to run the GNU profiling/coverage tools and also the Google Performance Tools (gperftools), but both seem to yield the same problem:
The library was built from master using ./configure --with-gcov=yes CXXFLAGS='-pg' CFLAGS='-pg' --xx-- hp$ ./perf/inproc_lat 10 1000000 message size: 10 [B] roundtrip count: 1000000 error in zmq_recvmsg: Interrupted system call hp$ ./perf/inproc_lat 20 10000 message size: 20 [B] roundtrip count: 10000 average latency: 39.693 [us] hp$ ./perf/inproc_thr 20 100000 message size: 20 [B] message count: 100000 error in zmq_recvmsg: Interrupted system call hp$ ./perf/inproc_thr 20 10000 message size: 20 [B] message count: 10000 mean throughput: 101855 [msg/s] mean throughput: 16.297 [Mb/s] --xx-- Clearly that's happening because of EINTR not being handled in the (performance) tests, dependant upon profiling granularity. The 6 million dollar questions being: 1. Should they be handled in the perf/*.cpp files to set an example and consequently make profiling work out of the box? 2. Am I barking up the wrong tree? In case of [1], as you may know in REQ/REP examples, it is not just a matter of retrying, since that returns EFSM due to the strict alternating pattern; unless I have read the manual pages incorrectly. I would appreciate if people familiar in the relevant dark arts can shed some light on this matter. -HP _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
