Does FreeBSD have sendmmsg or recvmmsg system calls?

Konstantin Belousov kostikbel at
Mon Jan 18 04:48:32 UTC 2016

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

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).

More information about the freebsd-threads mailing list