ros2 / ros2/rclcpp

Single-threaded executor can be starved by timers

Open
#392 6 comments 0 reactions 1 assignee View on GitHub

@mjcarroll is already working on this.

Since Mar 29, 2018.

bug hitlist ready
Dominant language
C++
Stars
805
Forks
564
Avg merge
1d 17h
Merged PRs (30d)
27

Description

Context (comes from https://github.com/ros2/demos/pull/187): A single-threaded executor has a timer scheduled for every N seconds, and also a service server.

Bug: If the timer callback takes >=N seconds to complete, the executor will never process service requests once the timer is triggered for the first time.

This is because of the combination of the following:

  1. When the spinning executor calls to get_next_executable, it does not call rcl_wait since the timer's ready, so the service is not marked as ready.
  2. Even if you force get_next_executable to always call wait_for_work so the server can get receive its request, the server will still not get processed by the executor because the timer will always get chosen first as the next_ready_executable.

Forcing get_next_executable to always call wait_for_work and giving timers lower priority in get_next_ready_executable will fix this situation, but it is inefficient to wait when it's not necessary, and I'm not sure checking timers last is a fix-all (could there be a parallel situation when the server needs to be the lowest priority?).

@dirk-thomas mentioned that a queue of some sort is probably more appropriate, so that get_next_executable processes events in the order that they were received.

For now, we have to recommend that users not permit timer callbacks to block for longer than the duration at which they're scheduled (this might be in our documentation somewhere already?).

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.