Io.net: fix compile error in receive and receiveTimeout
#25839
Conversation
Rexicon226
changed the title
receive and receiveTimeoutreceive and receiveTimeout
|
Can this sort of test even be made non-flaky? |
|
Probably not. Should I just remove it? |
|
We generally have a "no flaky tests" policy, to the point where intermittently failing tests get disabled until someone figures out what's wrong with them. So I think a test like this just isn't going to be practical unless someone has a reasonable suggestion for solving the problem of concurrent test processes using the same port. |
|
Understood, I'll remove this test then. Wait there's literally an |
Correctly uses the `netReceive` API. If an error was returned, we propagate that error, otherwise assert we only received one message.
If we use `undefined`, then `netReceive` can `@intCast` the control slice len to msghdr controllen, which is sometimes `u32`, even on 64-bit platforms. `init` just avoids this entirely by setting `control` to an empty slice rather than undefined.
Rexicon226
force-pushed
the
socket-bind-fix
branch
from
bb9904f to
71988d6
Compare
2 participants
Correctly uses the
netReceiveAPI.If an error was returned, we propagate that error, otherwise assert we only received one message.
follow-up question: for these types of tests where we need to bind to a specific port, how to decide the port?
can't use port 0 here, since we're binding, not allocating a port.
i just used port 8000, but i'd like to avoid hardcoding it if possible.