Does FreeBSD have sendmmsg or recvmmsg system calls?

[Boris Astardzhiev]

Hello,

Sorry for the delay of my reply. As far as I understand pthread_testcancel()
is not necessary in the recvmmsg syscall since cancellation is not quite
common
among apps. But if there is cancellation attempts as long as I use
__sys_recvmsg() instead
of the interposing approach on a cancel attempt recvmmsg() will return
EINTR which will get
me out?

Secondly, I guess it's better to use __sys_sendmmsg() similarly instead of
the
insterposing table regarding sendmmsg().

Lastly, regarding the manpage - should I extend send/recv(2) for the new
calls or
create new manpage files?

Best regards,
Boris Astardzhiev

On Mon, Jan 18, 2016 at 6:48 AM, Konstantin Belousov <kostikbel at gmail.com>
wrote:

> Added threads@ where this discussion is more appropriate.
>
> On Sun, Jan 17, 2016 at 10:18:53PM +0100, Jilles Tjoelker wrote:
> > This will typically work (if the cancellation occurs while blocked
> > inside __sys_recvmsg()) but has the usual problem of relying on [EINTR]:
> > lost wakeups. This is certainly less bad than using the interposable
> > recvmsg(), though, which would discard the already received data.
> >
> > As a slight modification, the first recvmsg could use the interposable
> > version, since there is no pending data at that point. This avoids
> > needing to call pthread_testcancel() manually.
> >
> > The regular cancellation code closes this race window using the
> > undocumented thr_wake() system call, on the thread itself, in the signal
> > handler for the cancellation signal. This causes the next attempt to
> > sleep(9) to fail with [EINTR]. (On another note, it appears to be
> > possible for user code (cleanup handlers and pthread_key_create()
> > destructors) to be called with thr_wake() still active, if the
> > cancellation signal handler is called immediately after the cancellation
> > point system call returns.)
> >
> > The race in recvmmsg could be removed using this mechanism but it
> > requires either a separate version of recvmmsg in libthr or a new
> > interface in libthr. I imagine the new interface as a new cancellation
> > type which causes cancellation point functions such as recvmsg() to fail
> > with a new errno when cancelled while leaving cancellation pending. This
> > seems conceptually possible but adds some code to the common path for
> > cancellation points. A new version of pthread_testcancel() with a return
> > value would be needed.
>
> Yes,  I should have remembered about TDP_WAKEUP.
>
> In fact, this discussion and recvmmsg() skeleton structured my
> understanding of the better split between libc and libthr. I start
> thinking that libthr should not interpose most of the syscalls. Instead,
> libthr should interpose (wrappers around) thr_cancel_enter*() and
> thr_cancel_leave(), the body of the cancellable syscalls should live in
> libc.
>
> The benefits are removal of double implementation of cancellable syscalls,
> more compact interface between libc and libthr, and potentially we can
> grow an _np extension which would allow user libraries to correctly
> implement composable cancellable functions (as needed for sendmmsg).
>