>> It really needs a new interface for recvfile/copyfile/whatever
>> anyway, as you can only specify an off_t for 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
Dan Maas wrote:
> >> It really needs a new interface for recvfile/copyfile/whatever
> >> anyway, as you can only specify an off_t for 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