Page MenuHomeFreeBSD

sendfile(2): document that EINTR never happens on non-blocking socket
AcceptedPublic

Authored by glebius on Thu, Jan 22, 3:40 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Jan 24, 9:36 PM
Unknown Object (File)
Thu, Jan 22, 7:52 PM
Unknown Object (File)
Thu, Jan 22, 5:28 PM
Unknown Object (File)
Thu, Jan 22, 3:46 PM
Unknown Object (File)
Thu, Jan 22, 2:46 PM
Unknown Object (File)
Thu, Jan 22, 12:57 PM
Unknown Object (File)
Thu, Jan 22, 7:17 AM
Unknown Object (File)
Thu, Jan 22, 5:49 AM
Subscribers

Details

Reviewers
chs
gallatin
markj
kib
jtl
jhb
Group Reviewers
network
Summary

The only sleep(9) in our sendfile(2)'s code path happens in sbwait(),
which in its turn is done only if the socket is blocking. Document this
fact as it is an important thing for application developers and may
simplify an application code quite a lot.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 70051
Build 66934: arc lint + arc unit

Event Timeline

This revision is now accepted and ready to land.Thu, Jan 22, 1:55 PM

There is a call to kern_writev() on the socket, is it true that it never returns EINTR for non-blocking socket?

And, this sounds more like the bug than a useful feature. Slow (network) syscalls must be interruptible.

In D54820#1253193, @kib wrote:

There is a call to kern_writev() on the socket, is it true that it never returns EINTR for non-blocking socket?

And, this sounds more like the bug than a useful feature. Slow (network) syscalls must be interruptible.

If the socket is non-blocking, then kern_writev() shall also not sleep on the socket buffer. With non-blocking sockets the syscall can't be slow and can't be interruptible cause it doesn't sleep(9) anywhere.

Ok, my reluctance to this documentation change is because such promise, of never returning specific error code, is very hard to fulfill. For instance, on intr NFS mount, VOP_GETATTR() can return EINTR, and so on.

I am not sure that this is a wise statement to make. It might be that your specific environment avoids some corner cases, but generally error codes are free to flow, so to say.

I agree. There's a reason EINTR is something userland is supposed to handle and restart in a documented way, and it's "so the kernel doesn't have to bend over backwards to restart things."

i know sendfile() is a bit more machinery, but i still don't like the idea of special casing this. This means that once application code is simplified, we'll be on the hook for maintaining this as an API behaviour.

If this is part of a larger problem of "sendfile can't EINTR in the middle of a transfer on a non-blocking socket because then we don't have a way to communicate up how much was written" well,
I have feelings about that too, having tried to use sendfile outside of netflix. :-)