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