Does FreeBSD have sendmmsg or recvmmsg system calls?
Boris Astardzhiev
boris.astardzhiev at gmail.com
Wed Jan 20 08:29:50 UTC 2016
jt>>
jt>> FBSDprivate_1.0 {
jt>> @@ -1051,4 +1053,6 @@ FBSDprivate_1.0 {
jt>> gssd_syscall;
jt>> __libc_interposing_slot;
jt>> __libc_sigwait;
jt>> + _sendmmsg;
jt>> + _recvmmsg;
jt>> };
jt>
jt>The _ versions need not be exported. Not exporting reduces code size and
jt>improves performance.
I'll fix it.
jt>> diff --git a/lib/libc/sys/recv.2 b/lib/libc/sys/recv.2
jt>> index 326e7ff..81a0201 100644
jt>> --- a/lib/libc/sys/recv.2
jt>> +++ b/lib/libc/sys/recv.2
jt>> [snip]
jt>
jt>I think the recv.2 and send.2 man pages are long enough as they are, and
jt>separate recvmmsg.3 and sendmmsg.3 pages will be clearer. This is also
jt>because recvmmsg/sendmmsg can be ignored when performance is good enough
jt>without them. This differs from what Konstantin thinks.
md>If they are to be made separate man pages can I suggest that the
md>recv/send(2) manpages be changes to at least make early reference to
md>the *mmsg() calls?
md>
md>Purely as marketing. My perception is that awareness of the *mmsg()
md>calls is rather limited.
Let me know the final decision then - whether in the existing manpages or
in new files.
jt>The Linux version has an additional parameter struct timespec *timeout
jt>(but only for recvmmsg, not for sendmmsg). Note that implementing this
jt>in a Linux-compatible manner has low overhead, since Linux only checks
jt>it between packets and never interrupts a wait because of this timeout
jt>(source: http://man7.org/linux/man-pages/man2/recvmmsg.2.html ).
That's right. Shall I try to implement the timeout part or leave
it the way it is now?
kb>Shouldn't i and rcvd be unsigned as well ? Shouldn't return value
kb>also be unsigned ?
I think i and rcvd should be unsigned whereas ret should not - after all
if an error occurred we get -1.
kb>> +
kb>> + if (vlen > VLEN_MAX)
kb>> + vlen = VLEN_MAX;
kb>Why is this restriction needed ?
Not needed. I'll remove it.
kb>> +
kb>> + rcvd = 0;
kb>> + for (i = 0; i < vlen; i++) {
kb>> + errno = 0;
kb>> + ret = __sys_recvmsg(s, &msgvec[i].msg_hdr, flags);
kb>> + if (ret < 0 || errno != 0) {
kb>I do not see why do you need to clear errno before, and then do this
test.
kb>Just check ret == -1, in which case errno was set from the immediate
syscall.
kb>
kb>> + if (rcvd != 0) {
kb>> + /* We've received messages. Let caller
know. */
kb>> + errno = 0;
kb>This cleaning is not needed as well. For successfull functions returns,
kb>errno value is undefined.
Wouldn't I confuse apps if they check errno in the follow case - I want to
receive two messages. The first __sys_recvmsg succeeds and then for the
second __sys_recvmsg fails. Thus errno will be != 0 and I'm telling the app
that I have received one message by returning 1 but errno will be != 0.
Is this correct?
Regards,
Boris Astardzhiev
On Wed, Jan 20, 2016 at 9:31 AM, Konstantin Belousov <kostikbel at gmail.com>
wrote:
> On Tue, Jan 19, 2016 at 01:58:27PM +0200, Boris Astardzhiev wrote:
> > +int
> > +recvmmsg(int s, struct mmsghdr *msgvec, unsigned int vlen, int flags)
> > +{
> > + int i, ret, rcvd;
> Shouldn't i and rcvd be unsigned as well ? Shouldn't return value
> also be unsigned ?
> > +
> > + if (vlen > VLEN_MAX)
> > + vlen = VLEN_MAX;
> Why is this restriction needed ?
>
> > +
> > + rcvd = 0;
> > + for (i = 0; i < vlen; i++) {
> > + errno = 0;
> > + ret = __sys_recvmsg(s, &msgvec[i].msg_hdr, flags);
> > + if (ret < 0 || errno != 0) {
> I do not see why do you need to clear errno before, and then do this test.
> Just check ret == -1, in which case errno was set from the immediate
> syscall.
>
> > + if (rcvd != 0) {
> > + /* We've received messages. Let caller
> know. */
> > + errno = 0;
> This cleaning is not needed as well. For successfull functions returns,
> errno value is undefined.
>
> > + return (rcvd);
> > + }
> > + return (-1);
> > + }
> > +
> > + /* Save received bytes */
> > + msgvec[i].msg_len = ret;
> > +
> Extra empty line.
> > + rcvd++;
> > + }
> > +
> > + return (rcvd);
> > +}
>
More information about the freebsd-threads
mailing list