[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <44C90987.1040200@redhat.com>
Date: Thu, 27 Jul 2006 11:44:23 -0700
From: Ulrich Drepper <drepper@...hat.com>
To: Badari Pulavarty <pbadari@...ibm.com>
CC: Zach Brown <zach.brown@...cle.com>,
Sébastien Dugué <sebastien.dugue@...l.net>,
Christoph Hellwig <hch@...radead.org>,
Evgeniy Polyakov <johnpol@....mipt.ru>,
lkml <linux-kernel@...r.kernel.org>,
David Miller <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
Suparna Bhattacharya <suparna@...ibm.com>
Subject: Re: [3/4] kevent: AIO, aio_sendfile() implementation.
Badari Pulavarty wrote:
> Before we spend too much time cleaning up and merging into mainline -
> I would like an agreement that what we add is good enough for glibc
> POSIX AIO.
I haven't seen a description of the interface so far. Would be good if
it existed. But I briefly mentioned one quirk in the interface about
which Suparna wasn't sure whether it's implemented/implementable in the
current interface.
If a lio_listio call is made the individual requests are handle just as
if they'd be issue separately. I.e., the notification specified in the
individual aiocb is performed when the specific request is done. Then,
once all requests are done, another notification is made, this time
controlled by the sigevent parameter if lio_listio.
Another feature which I always wanted: the current lio_listio call
returns in blocking mode only if all requests are done. In non-blocking
mode it returns immediately and the program needs to poll the aiocbs.
What is needed is something in the middle. For instance, if multiple
read requests are issued the program might be able to start working as
soon as one request is satisfied. I.e., a call similar to lio_listio
would be nice which also takes another parameter specifying how many of
the NENT aiocbs have to finish before the call returns.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
Download attachment "signature.asc" of type "application/pgp-signature" (252 bytes)
Powered by blists - more mailing lists