-
Notifications
You must be signed in to change notification settings - Fork 3k
Refactor tcpsocket tests to use sigio and not to wait #9794
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
Refactor tcpsocket tests to use sigio and not to wait #9794
Conversation
continue; | ||
} else if (recvd < 0) { | ||
TEST_FAIL(); | ||
int recvd = sock.recv(&(tcp_global::rx_buffer[bytes2recv_total - bytes2recv]), bytes2recv); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think you should remove the while() loop.
You are supposed to loop UNTIl you get the WOULD_BLOCK.
Only then you are guaranteed to receive sigio() event.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I understand correctly... The tcpsocket_echotest_nonblock_receive()
function is called from sigio handler. I thought it is supposed to trigger on the event to be sure the data is there waiting to be read?
Perhaps I am missing something about how the sigio works?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For example, if the driver received 2kB of data.. sends sigio()
event to notify that there is new data to be read, and you read 1kB. It does not send another event, because there was not change in the state.. the device is still readable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sigio()
notifies that there is change of state.
readable -> not readable or
not readable -> readable or
connected -> disconnected or
connecting -> connected or
new connections acceptable -> no new connections
etc...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now I see. Then I will also fix the tlssocket echo tests as I made the same mistake there some time ago.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Brough the loop back into the receiver both for tcp and tls socket tests. Thanks for pointing this out!
@michalpasztamobica, thank you for your changes. |
63e2792
to
b9ece1b
Compare
b9ece1b
to
700f0e6
Compare
@VeijoPesonen , thanks for your remarks. I just pushed improved code. |
700f0e6
to
999273f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
CI started while waiting on one or two more people to complete reviews |
Test run: SUCCESSSummary: 10 of 10 test jobs passed |
Description
As previously done for TLSSockets - we don't want the receiver thread to do a busy wait.
I decided not to touch the UDPSocket echo tests as they do packet counting (and accept some missing packets ratio), so the design there would have to be different, but if you think it's reasonable to rewrite that test to, I can do it as well.
Pull request type
Reviewers
@SeppoTakalo
@AriParkkila
@VeijoPesonen
@KariHaapalehto
@mtomczykmobica
@tymoteuszblochmobica