Fix recvmmsg(2) implementation

[codeslinger]

There were two problems discovered with the recvmmsg(2) implementation
that this changeset attempts to fix:

1. As mentioned in Recvmmsg can return fewer than specified number of messages #1325, recvmmsg(2) can return fewer
   messages than requested, and
2. Passing the return value of recvmmsg(2) as the number of bytes in
   the messages received is incorrect.

This changeset incorporates the proposed fix from /issues/1325,
as well as passing the correct value (mmsghdr.msg_len) for the number
of bytes in a given message.

[codeslinger]

I don't quite understand why the CI didn't pass on stable. On my Linux machine, the test-aio-drop test passes. It appears to be failing on other open PRs against this repo, as well, without any associated changes to anything that would affect that test. Anybody have any ideas on how to fix this?

[asomers]

Do you know of any way to force the condition described in #1325, so we can test for it?

[asomers]

BTW, the failure of test-aio-drop is not related to this PR. I suspect it's due to a bug in glibc. But I've never been able to reproduce it locally, so I'm not sure.

[codeslinger]

Re: testing: as far as the actual problem that existed prior to this PR, you should be able to:

1. Create a UDP socket
2. In one thread, send the socket some number of messages, X
3. In another thread, call recvmmsg with a number of mmsghdrs > X and a flags value of MSG_DONTWAIT (or MSG_WAITFORONE on Linux)
4. Ensure that recvmmsg does in fact return with a value of X immediately

I can add a test for that to this PR if that seems acceptable.

[codeslinger]

Added a test for short reads when using MSG_DONTWAIT.

[asomers]

Looks good! Could you also please add a CHANGELOG entry?

[asomers]

Actually, in the interest of expediency, I'm going to merge this now and add a CHANGELOG entry later.

[asomers]

bors r+

[bors]

Build succeeded:

• FreeBSD 11.4
• continuous-integration/travis-ci/push