Closed ghost closed 3 years ago
Ping!
If anyone is wondering why this is necessary, consider the following code:
if (conn->isReadyReceive(ms_timeout)) {
conn->receiveMsg(res);
}
If you were hoping this code would always result in a non-blocking read, well that's not guaranteed.
The problem is that isReadyReceive
can only check if any data is ready for reading.
On the other hand, receiveMsg
will block until all data has been read.
So if you receive the first few bytes of a message, but then the connection hangs:
isReadyReceive
will call rawPoll
and return true.receiveMsg
will call receiveBytes
, which will enter its internal while loop.receiveBytes
will successfully receive a few bytes.receiveBytes
will no longer getting any bytes.while (remainBytes > 0) {
.The problem is that there is no way to escape the internal while loop, and doing isReadyReceive
doesn't actually prevent receiveMsg
from getting stuck. The problem is worse for large messages.
@realanton I would if I could but this is actually the ROS Industrial repo! :laughing:
Newer version in #267.
See also #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 areceiveBytes
member function with a timeout parameter. (So if any other classes inherit fromSmplMsgConnection
, they will need to be updated.)Also, a few random whitespace fixes I couldn't resist.