Does FreeBSD have sendmmsg or recvmmsg system calls?

[Konstantin Belousov]

On Mon, Jan 04, 2016 at 09:11:08AM +0000, Mark Delany wrote:
> On 04Jan16, Konstantin Belousov allegedly wrote:
> > On Sun, Jan 03, 2016 at 09:47:20PM +0000, Mark Delany wrote:
> > > Eg, if a signal arrives after
> > > more than zero packets have been processed by recvmmsg() what is the
> > > correct return value? -1 or the count of messages returned?
> > 
> > This is really not a question to consider different answers. Unix
> > already made a (right, IMO) decision there, e.g. for read(2) syscall.
> > If any data was actually read, the length of the consumed data must be
> > returned, and not the error.
> 
> So the error is lost? In that case, recvmmsg() is not the same as an
> iteration over recvmsg().
> 
> Besides, a signal isn't necessarily an error. Think SIGALRM.
The signal is the signal, it is not an error in any imaginable sense.

> 
> The point is that recvmmsg() may have populated the struct mmsghdr*
> with a number of inbound messages then it is interrupted by a signal.
> 
> It then has a choice of telling user space that it has 'n' messages to
> be processed or -1/EINTR that a signal occurred.
> 
> If the choice is the former, then the signal is lost. If the choice is
> the latter then 'n' messages are lost. There is no return possible
> which indicates that there are messages *and* a signal.
Why is a signal lost in the scenario you described ? Signal interrupted
the sleep, which is the only required interaction between a signal
delivery and slow syscalls. EINTR (or ERESTART) is the placeholder for
syscalls to return something when there is no reasonable return value
otherwise. E.g. read(2) without any data already accepted needs to
return EINTR and not 0, to not confuse apps with ^D or EOF. But this is
_not_ the mechanism used to deliver signals.

> 
> Thinking out loud here: are there any other "batch" system calls like
> recvmmsg() that can offer guidance?

You stripped the part of my message which give you the example: read(2)
(on slow devices and sockets).