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

William Woodall william at osrfoundation.org
Thu Mar 6 05:06:39 UTC 2014


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.


>
> Daniel.
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at lists.ros.org
> http://lists.ros.org/mailman/listinfo/ros-users
>
>


-- 
William Woodall
ROS Development Team
william at osrfoundation.org
http://williamjwoodall.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20140305/01794c3a/attachment.html>


More information about the ros-users mailing list