improve asynchonous publishing performance

[dirk-thomas]

@esteve @tfoote @wjwwood Please review.

[wjwwood]

Reading briefly about using time.sleep(0) as a yield reveals that it may not work that way on OS X or Windows. What are you trying to accomplish with that? It seems like there should be a better way to do that.

[wjwwood]

Maybe not, that seems to be the recommended way to do it.

[wjwwood]

At least this recommends calling a delayfunc with 0:

http://docs.python.org/2/library/sched.html

And later mentions that delayfunc is usually time.sleep.

[dirk-thomas]

Please try the above example script with e.g. three listening rostopics on OS X in order to figure out how it behaves on that system.

I was able to get to 1kHz without a problem - and I think that is a restriction of the above script. If you e.g. invoke publish five times per loop I could easily go beyond that frequency.

[wjwwood]

When disconnecting a rostopic hz I get this traceback:

Exception in thread Thread-14:
Traceback (most recent call last):
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 808, in __bootstrap_inner
    self.run()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 761, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/Users/william/hydro/install/lib/python2.7/site-packages/rospy/impl/tcpros_pubsub.py", line 422, in _run
    with self._cond:
  File "/Users/william/hydro/install/lib/python2.7/site-packages/rospy/impl/tcpros_pubsub.py", line 388, in __getattr__
    return getattr(self._connection, name)
AttributeError: 'TCPROSTransport' object has no attribute '_cond'

From what I can see, this should never have worked? Maybe it was always broken, but this change exposed it?

[wjwwood]

Other than the traceback from above, this patch does indeed resolve the issue described in #373.

[dirk-thomas]

You are running old code: #369.

[jonbinney]

I tested this on my system, and it does fix #373 for me.

[jonbinney]

Assuming this patch gets merged, will it get backported to hydro-devel?

[dirk-thomas]

Yes, it will definitely be backported due to its significant impact and the fact that nearly no code is actually using the queuing yet and therefore the chance of a regression a very slim.

[dirk-thomas]

Cherry-picked to hydro-devel: f577021

[jonbinney]

Thanks @dirk-thomas !