sendfile(2) behaviour has changed?
Quoted 5 lines
Quoted 3 lines
It really needs a new interface for recvfile/copyfile/whatever anyway, as you can only specify an
off_tfor the from fd at present.Ummm, you can use
lseek()on the 'to' fd perhaps?
Wouldn't that be non-atomic and therefore likely to cause problems with concurrent writes?
Regards,
Dan
Quoted 8 lines · Dan Maas
Quoted 5 lines
Quoted 3 lines
It really needs a new interface for recvfile/copyfile/whatever anyway, as you can only specify an
off_tfor the from fd at present.Ummm, you can use
lseek()on the 'to' fd perhaps?Wouldn't that be non-atomic and therefore likely to cause problems with concurrent writes?
sendfile() from a mapped tmpfs file is a nice way to get zero-copy writes of program-generated data, for example HTTP headers.
If it were possible to recvfile() _to_ a tmpfs file, you could use this to implement zero-copy forwarding between sockets, in userspace, while still having a program inspect part of the data and possibly change it. There are lots of proxy services that could potentially use this.
This is an example of when you'd want many concurrent writes to the same file. (Naturally, for performance, you'd want to use one large tmpfs file and allocate portions of it on the fly, rather then multiple opens or lots of small files).
enjoy,
-- Jamie