the realities of splice

the realities of splice

Posted Jan 20, 2005 4:17 UTC (Thu) by bronson (guest, #4806)
Parent article: The evolution of pipe buffers

The code we saw last week was sleek and pretty. This week, in making it more useful, it appears to have grown all sorts of hair. It will be interesting to see how well it can be cleaned back up.

Is splice only intended for pipes? I hope that eventually I could splice, say, a file to a socket (a la sendfile), socket to a socket, etc.

---

to post comments

the realities of splice

Posted Jan 20, 2005 4:40 UTC (Thu) by bradfitz (subscriber, #4378) [Link]

I hope that eventually I could splice, say, a file to a socket (a la sendfile), socket to a socket, etc.

That's the plan, as I've been reading it.

the realities of splice

Posted Jan 20, 2005 5:13 UTC (Thu) by dlang (guest, #313) [Link]

from his posts in the 19th it will remain pipe <-> other

so you can do file -> pipe -> socket but not file -> socket

the realities of splice

Posted Jan 20, 2005 14:29 UTC (Thu) by alangley (guest, #23266) [Link] (1 responses)

Actually, you have to wonder why it's a new syscall at all. The interface is almost exactly the same as sendfile, so why has Linus added another syscall at all?

(and the outfd, infd arguments are round the wrong way at the moment)

AGL

the realities of splice

Posted Oct 11, 2006 15:19 UTC (Wed) by Niam (guest, #41009) [Link]

So I don't understand qhat is this new syscall for!!
Sendfile is seems much better, 'cos it can manipulate with any fd...

Only a "plus" - it's faster[but it works with pipes!!!].
It seems to me that better to modify sendfile call for pipes mode.

Now, if I write new progrom I should write
#ifdef __splice
splice(..)
#elif __tee
tee(...)
#else
sendfile(..)
#endif

I can't see what are them really for...