Skip to content

WaitSet::wait does not return if data was send before WaitSet::attachState #1855

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
mossmaurice opened this issue Jan 24, 2023 · 1 comment · Fixed by #1856
Closed

WaitSet::wait does not return if data was send before WaitSet::attachState #1855

mossmaurice opened this issue Jan 24, 2023 · 1 comment · Fixed by #1856
Assignees
Labels
bug Something isn't working
Milestone

Comments

@mossmaurice
Copy link
Contributor

mossmaurice commented Jan 24, 2023

Required information

Operating system:
Ubuntu 20.04.3 LTS

Compiler version:
GCC 8.4.0

Affected release(s):

  • master branch
  • iceoryx Blueberry v2.0.2

Observed result or behaviour:
WaitSet::wait does not return when there is data in the queue aka hasData() / hasRespones() / hasRequests() returning true at the time of attaching an object to the WaitSet and without further notification.

Expected result or behaviour:
If data is available in the queue when attached, the WaitSet::wait should immediately return.

Conditions where it occurred / Performed steps:

The issue was uncovered while working on ros2/rmw_iceoryx#84 with request/response communication. The same problem should also occur with pub/sub communication, but I have not explicitly reproduced that.

  1. Start app Alice with iox::popo::Server
  2. Start app Bob with iox::popo::Client
  3. Send a request with iox::popo::Client from app Bob
  4. From app Alice iox::popo::Server sends response
  5. Only now, app Bob creates a ìox::popo::WaitSet
  6. App Bob attaches the client with iox::popo::ClientState::HAS_RESPONSE
  7. App Bob then calls WaitSet::wait which never returns because the ConditionNotifier::notify() call and its trigger is missing for the data which is already stored in the queue
@mossmaurice mossmaurice added the bug Something isn't working label Jan 24, 2023
@mossmaurice mossmaurice added this to the High prio milestone Jan 24, 2023
@mossmaurice mossmaurice self-assigned this Jan 24, 2023
mossmaurice pushed a commit to ApexAI/iceoryx that referenced this issue Jan 24, 2023
mossmaurice pushed a commit to ApexAI/iceoryx that referenced this issue Jan 24, 2023
mossmaurice pushed a commit to ApexAI/iceoryx that referenced this issue Jan 24, 2023
mossmaurice pushed a commit to ApexAI/iceoryx that referenced this issue Jan 25, 2023
mossmaurice pushed a commit to ApexAI/iceoryx that referenced this issue Jan 25, 2023
…t::wait' for a 2nd time

Signed-off-by: Simon Hoinkis <[email protected]>
@mossmaurice mossmaurice reopened this Jan 25, 2023
@mossmaurice
Copy link
Contributor Author

Will be closed once merged on release_2.0 branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant