ntd's profile - activity

Re number of connections: AFAIK, all roscpp's IO happens in a select loop ( https://github.com/ros/ros_comm/blob/... ), so one thread can service many connections. The select() call, though is O(n) in the number of connections. There is a Linux specific epoll() which handles large numbers of connections more efficiently. This page discusses some general networking/scalability issues: http://www.kegel.com/c10k.html .

Re latency: roscpp message latency is ~100us on recent Intel CPUs under Linux PREEMPT_RT. This is 10-20 times slower than direct kernel sockets and IPC. Benchmark code: https://github.com/ndantam/ipcbench Some discussion in our recent article: http://dx.doi.org/10.1109/MRA.2014.23... .

I am trying to call roscpp within another program that uses SIGPIPE. ROS is blocking this (in https://github.com/ros/ros_comm/blob/... ) and this breaks things.

Why is SIGPIPE ignored here? Presumably, this would be to prevent the default handler from terminating the process when a socket is disconnected.

My current workaround is to unmask SIGPIPE via sigprocmask() after the ROS libraries are loaded. This seems to be working fine in that I can communicate via ROS and the rest of the program can use SIGPIPE as it needs to. Are there any potential subtle errors that could arise from this?

Ideally, it seems that there should be an option to prevent roscpp from initially blocking SIGPIPE rather than it unconditionally modifying the process-global state.

I have also had this problem with Lucid i386.

There seems to be a version mismatch in the libopencv2.3 package. The version currently in the repo is 2.3.1+svn6514+branch23-4~lucid while most of the ros-electic packages depend on the exact libopencv=2.3.1+svn6514+branch23-1~lucid version, which has now been removed from the repo.

The fix probably needs to happen on the repo maintainer end and should be one of:

• Update ros-electric dependencies on all packages to libopencv=2.3.1+svn6514+branch23-4~lucid
• Update ros-electric dependencies on all packages to a more permissive version range so that this type of error won't happen when the minor package revision is incremented.