Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > So a "splice_eof()" sounds fine to me, and we'd make the semantics be > the current behavior: > > - splice() sets SPLICE_F_MORE if 'len > read_len' > > - splice() _clears_ SPLICE_F_MORE if we have hit 'len' > > - splice always sets SPLICE_F_MORE if it was passed by the user > > BUT with the small new 'splice_eof()' rule that: > > - if the user did *not* set SPLICE_F_MORE *and* we didn't hit that > "use all of len" case that cleared SPLICE_F_MORE, *and* we did a > "->splice_in()" that returned EOF (ie zero), *then* we will also do > that ->splice_eof() call. > > The above sounds like "stable and possibly useful semantics" to me. It > would just have to be documented. > > Is that what people want? That's easier to implement, I think. That's basically what I was trying to achieve by sending a zero-length actor call, but this is a cleaner way of doing it, particularly if it's added as a socket op next to ->sendmsg(). Otherwise I have to build up the input side to try and tell me in advance whether it thinks we hit an EOF/hole/whatever condition. The problem is that, as previously mentioned, it doesn't work for all circumstances - seqfile, pipes, sockets for instance. Take the following scenario for example: I could read from a TCP socket, filling up the pipe-buffer, but not with sufficient data to fulfill the operation. Say I drain the TCP socket, but it's still open, so might produce more data. I then call the actor, which passes all the data to sendmsg() with MSG_SPLICE_PAGES and MSG_MORE and clears the buffer. I then go round again, but in the meantime, the source socket got shut down with no further data available and do_splice_to() returns 0. There's no way to predict this, so having a ->splice_eof() call would handle this situation. David
