Re: sendfile and aio_write: a match made in heaven?

[Daniel R. Kegel]

Ananth Ananthanarayanan wrote:
> > The aio_write interface could be extended [to handle sendfile]
> > by adding two new fields to struct aiocb:
> >    int  aio_filedes2;
> >    off_t aio_offset2;
> > These would only be checked if the aio_buf field were NULL,
> > in which case aio_write would cause bytes to be transferred
> > from aio_filedes2 to aio_filedes1.
> 
> The idea of extending aio_*() to include sendfile() is good,
> but I'm not sure you'd want to do that with aio_write(), or
> for that matter extend aiocb with extra fields. ...
> Instead, may I suggest aio_sendfile(aiocb, int outfd, int outoffset),
> where aiocb defines the "input" & the outfd/offset define the "output".
> We need an aiocb to support aio_error(), aio_return(),
> aio_suspend(), etc ... to provide a handle to the request in progress.

Defining aio_sendfile() would solve the immediate problem, but doing it that
way would not allow invoking sendfile() from lio_listio().
Sure, you could define an AIO_SENDFILE value for the aio_lio_opcode field 
of the aiocb structure, but unless you extend aiocb as I suggested,
there's nothing for that opcode to work with.

I'm not saying a lot of people (or anyone) uses lio_listio(), but it's
part of the Single Unix Standard (see
http://www.opengroup.org/onlinepubs/007908799/xsh/lio_listio.html)
and if we want our asynch sendfile stuff to fit into SUS someday,
we'd better not adopt an interface that would make that impossible.

To answer your concern about defining a special meaning for aio_buf being NULL,
I'm happy with defining aio_sendfile(struct aiocb *aiocbp), but 
let's add the two fields I suggested rather than adding arguments;
aio_ calls generally have just one argument, and aio_sendfile shouldn't be an 
exception.
- Dan