[ros-users] RFC: warning for (lacking) queue_size for python publishers in Indigo?

Daniel Stonier d.stonier at gmail.com
Thu Mar 6 08:32:01 UTC 2014


On 6 March 2014 14:06, William Woodall <william at osrfoundation.org> wrote:

> On Wed, Mar 5, 2014 at 8:14 PM, Daniel Stonier <d.stonier at gmail.com>wrote:
>
>>
>>
>>
>> On 6 March 2014 10:58, Dirk Thomas <dthomas at osrfoundation.org> wrote:
>>
>>> We are looking for feedback from ROS users on a very specific question
>>> for rospy in Indigo.
>>>
>>> In the past rospy publishers sent the messages synchronously to each
>>> connection.
>>> That becomes a problem when one of the underlying network buffers runs
>>> full (which implies that it blocks).
>>> This commonly happens when e.g. using a connection over wlan and the
>>> connectivity is lost.
>>> The client code would then block on the publish() call for an
>>> undetermined amount of time (potentially forever).
>>>
>>> Therefore in Hydro an optional keyword argument was introduced to the
>>> rospy.Publisher constructor: queue_size=None (see [1])
>>>
>>> The default value of `None` maintains the previous behavior (synchronous
>>> behavior, no queuing).
>>> When an integer value is passed a queue with the maximum size of N is
>>> used to queue published messages which are then send to each connection
>>> from separate threads.
>>> (A size of zero means an infinite queue, which can be dangerous.)
>>>
>>> The implementation follows the existing roscpp implementation - except
>>> that in roscpp that argument is required.
>>> It is definitely not possible to make the argument in Python required as
>>> well since that would imply breaking every existing Python publisher.
>>>
>>> Therefore we have two options how to handle this in Indigo:
>>>
>>> a) The constructor could output a warning when the queue_size argument
>>> is missing in order to notify users / developers to update the code and
>>> actually provide a reasonable queue_size.
>>>    The warning would be printed using the Python warnings module and can
>>> therefore be omitted by setting an environment variable (see [2]).
>>>
>>> b) We keep the code as it is in Hydro meaning messages are by default
>>> published synchronously.
>>>    Users can use the optional keyword but are not given any indication
>>> from the code at runtime.
>>>
>>> The tutorials as well as Indigo migration guide will mention whatever
>>> option will finally be used.
>>>
>>> Which option would you prefer for Indigo?
>>>
>>> Thank you for your feedback,
>>> - Dirk
>>>
>>>
>>> [1] http://wiki.ros.org/rospy/Overview/Publishers%20and%20Subscribers
>>> [2] https://github.com/ros/ros_comm/pull/372
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at lists.ros.org
>>> http://lists.ros.org/mailman/listinfo/ros-users
>>>
>>
>>
>> I haven't looked into the api here, but I'm guessing from the above
>> description that the default roscpp implementation accepts a non-zero(?)
>> queue size and consequently is not synchronous. Is that true?
>>
>
> Yes.
>
>
>>
>> If it is, what is the primary reason for wanting the python
>> implementation proposed in b) to be different, i.e. synchronous by default?
>> Is the threaded non-blocking implementation particularly expensive?
>>
>
> Maybe it's not clear in Dirks email, but the behavior is not what we are
> trying to decide on. The current behavior is that with no queue_size
> provided it will continue to do what it has always done (in order to
> preserve the behavior for backwards compatibility), but you can now treat
> it like roscpp by providing the queue_size argument. The only thing we have
> to decide is (a) if we want a warning when no queue_size is provided (to
> encourage people to change their code) or (b) to have none.
>

Ok, had a longer read of all the github threads to work out the motivation
behind this.

Right now, it appears that the default setting is easily broken for a
minority of use cases and non-intuitive to debug. And that would be good to
amend. Better to have it working everywhere and optimisable for power use
cases.

Adding some notes on the wiki probably won't do much to notify existing
users - typically copy/pasting from nearby code what I do.

So back to my earlier question - is setting a queue size expensive in the
python implementation? If there isn't a technical weakness there, then I'm
all for a) warnings and a migration point sometime in the future - it
wouldn't be very costly to mechanically search and destroy all
rospy.Publisher instances in a ros workspace.

Daniel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20140306/c385a683/attachment.html>


More information about the ros-users mailing list