srcIsRegularFile check in net/http/server.go response.ReadFrom()

EDIT: I answered my own question, but am following up with a suggestion

I am kind of curious why there is a check for the source being a regular file in addition to the underlying writer being a ReaderFrom. This is defeating the use of splice() on Linux when copying the output of a socket into a response (socket to socket can splice).

If the source turns out not to be splice-or-sendfile’able after all, there’s nothing lost if we proceed along, as we know the writer is at least a ReaderFrom and the ReadFrom() calls will devolve into our buffered copy anyway, thus no worse off than the current behavior.

It seems to me this check is unnecessary and, in this case, is actually hurting? I can’t find any harm if that check is removed.

I traced this to issue #5660, which I probably should have found and read before asking. This feels like it is papering over a problem though as it does kill a nice optimization that happens with socket to socket on Linux.

It seems to me we could solve this issue less astonishingly if we always do the first sniffLen as a normal read (regardless if needsSniff()) to both satisfy the sniff but also block until data is readable, which is the main complaint. Body lengths less than 512 bytes won’t benefit much from sendfile/splice anyway, and while we still have the extra syscall and I/O operation, we still had one before anyway. Would anyone like to shoot this down? I may try to submit a bug with a suggested patch.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.