Skip to content
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

Unit tests for XmlRpcDispatch #1232

Merged

Conversation

trainman419
Copy link
Contributor

  • Fix handling of out-of-band (Exception) request and and event processing to match previous select() implementation.
  • Update comments to describe the events that actually trigger and Exception state.
  • Unit tests for XmlRpcDispatch to verify that it calls poll() correctly, requests the correct events and calls the correct handler for those events.

* Fix handling of out-of-band (Exception) request and and event
processing to match previous select() implementation.
* Update comments to describe the events that actually trigger and
Exception state.
* Unit tests for XmlRpcDispatch to verify that it calls poll()
correctly, requests the correct events and calls the correct handler
for those events.
@trainman419
Copy link
Contributor Author

Bump. @dirk-thomas @mikepurvis ?

if (readable && (pfd.revents & POLLIN_CHK))
newMask &= src->handleEvent(ReadableEvent);
if (writable && (pfd.revents & POLLOUT_CHK))
newMask &= src->handleEvent(WritableEvent);
if (pfd.revents & POLLEX_CHK)
if (oob && (pfd.revents & POLLEX_CHK))
newMask &= src->handleEvent(Exception);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you describe more about what is going on here? Is this a behaviour change/fix which arose as a result of the added tests?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I initially wrote this test against the previous version of this, which was using select(), since our internal fork of ROS is mostly based on Indigo. When I updated this test to the most recent version of ros_comm to get the poll() implementation, it no longer behaved the same way when there was an exception event on the socket. This fixes it so that the poll() implementation behaves more like the original select() implementation.

Also of note is that for TCP sockets, the exception event actually indicates the reception of out-of-band data over the TCP connection, and doesn't indicate an error event on the socket. I've updated the comments and the implementation to reflect this and restore the original behavior.

(I light of this I think the original behavior might be a little misguided, but my goal here is to preserve all of the existing behavior that isn't clearly a bug.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fun, okay. Yeah, we're having some similar issues with select/poll/epoll subtleties over in #1217.

@mikepurvis
Copy link
Member

This all seems reasonable to me, but TBH I've never really had to grapple with these internals before, so my thumbs-up is not the most valuable one.

Copy link
Member

@dirk-thomas dirk-thomas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

I will wait with the merge until CI is green and @trainman419 had a chance to answer the pending question from @mikepurvis.

@dirk-thomas
Copy link
Member

@ros-pull-request-builder retest this please

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants