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

simple_message should include receive timeout #34

Closed
JeremyZoss opened this issue Aug 23, 2013 · 1 comment · Fixed by #267
Closed

simple_message should include receive timeout #34

JeremyZoss opened this issue Aug 23, 2013 · 1 comment · Fixed by #267

Comments

@JeremyZoss
Copy link
Member

Currently, the simple_message receive calls will block forever until the requested message data is received or the connection is dropped/reset. For some applications, it may be helpful for the user to be able to specify a timeout on the socket-read.

The recent fix to Issue #25 helps provide some of the low-level socket structure needed for this enhancement. But, this enhancement will require additional changes to the higher-level messaging layers to pass the timeout error status up to user-level code.

Jmeyer1292 pushed a commit to Jmeyer1292/industrial_core that referenced this issue Feb 14, 2017
@ghost
Copy link

ghost commented Nov 21, 2019

I would also like this feature!

gavanderhoorn pushed a commit to gavanderhoorn/industrial_core that referenced this issue Jun 23, 2021
See also ros-industrial#34. Existing receive functions are unaffected, and behave
exactly as before. The only big difference is that all classes
inheriting from `SmplMsgConnection`, i.e., `SimpleSocket` must now
override a `receiveBytes` member function with a timeout
parameter. (So if any other classes inherit from `SmplMsgConnection`,
they will need to be updated.)
@gavanderhoorn gavanderhoorn linked a pull request Jun 23, 2021 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

2 participants